JP2023087420A - 秘匿化装置、秘匿化方法、および秘匿化プログラム - Google Patents

Abstract

【課題】データ保護のレベルが異なるユーザ間での同時閲覧の利便性の向上を図ること。【解決手段】プログラムを実行するプロセッサと、前記プログラムを記憶する記憶デバイスと、を有する秘匿化装置は、１以上の項目と当該項目の内容を示すデータとを有するリソースについて、ユーザの属性および前記項目の属性に基づいて前記データの秘匿化を前記ユーザごとに制御する秘匿化処理と、前記ユーザごとに前記秘匿化処理が実行された秘匿化結果に基づく前記リソースを、前記ユーザごとの端末に出力する第１出力処理と、を実行する。【選択図】図１

Description

本発明は、データを秘匿化する秘匿化装置、秘匿化方法、および秘匿化プログラムに関する。

ＧＤＰＲ（Ｇｅｎｅｒａｌ Ｄａｔａ Ｐｒｏｔｅｃｔｉｏｎ Ｒｅｇｕｌａｔｉｏｎ）のような個人情報等のデータ保護を目的とした制約により、ストレージ装置の管理ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）のような顧客情報を含むリソースの表示および管理を目的としたＵＩでは、閲覧するユーザにより秘匿すべき情報が変化する。秘匿すべきユーザに対して情報を開示する場合は、画面のスクリーンショットを採取したのちに手動で顧客情報を隠して提供したり、顧客情報を含まない擬似環境を構築した上で当該擬似環境にアクセスしたりする方法が採用されている。このように、静的な表示制御で秘匿情報をマスキングする公知技術として、下記特許文献１がある。

下記特許文献１は、新規利用者への対応等のメンテナンスに手間を要さずに、文字列、画像または動画等を含んだ閲覧情報に対し、利用者の閲覧権限レベルに応じて柔軟に機密箇所の隠蔽領域を制御する閲覧情報管理システムを開示する。

この閲覧情報管理システムは、マスクレイヤデータの選択手段とマスクレイヤデータの合成手段を有し、前記選択手段は、隠蔽領域が描かれた複数のマスクレイヤデータから、利用者の閲覧権限レベルに応じて単数または複数のマスクレイヤデータを選択し、前記合成手段は、閲覧情報である原本データに対して、前記選択手段によって選択された単数または複数のマスクレイヤデータを合成し、利用者に対して、前記閲覧情報に隠蔽処理を行って、提供する。

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

しかしながら、データ保護のレベルが異なるユーザ間で本番環境を共有することができず、リアルタイムに同時作業することが困難である。また、企業間での協業や問題解決においても、直接同じ環境を共有することが許されず、多くの時間とコストがかかる。

本発明は、データ保護のレベルが異なるユーザ間での同時閲覧の利便性の向上を図ることを目的とする。

本開示技術の秘匿化装置は、プログラムを実行するプロセッサと、前記プログラムを記憶する記憶デバイスと、を有する秘匿化装置であって、前記プロセッサは、１以上の項目と当該項目の内容を示すデータとを有するリソースについて、ユーザの属性および前記項目の属性に基づいて前記データの秘匿化を前記ユーザごとに制御する秘匿化処理と、前記ユーザごとに前記秘匿化処理が実行された秘匿化結果に基づく前記リソースを、前記ユーザごとの端末に出力する第１出力処理と、を実行することを特徴とする。

本発明の代表的な実施の形態によれば、データ保護のレベルが異なるユーザ間での同時閲覧の利便性の向上を図ることができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

図１は、秘匿化システムのハードウェア構成例を示すブロック図である。 図２は、秘匿化システムにおけるデータ参照例を示す説明図である。 図３は、秘匿化システムにおけるデータ更新例１を示す説明図である。 図４は、秘匿化システムにおけるデータ更新例２を示す説明図である。 図５は、セッションテーブルの一例を示す説明図である。 図６は、リソースタイプテーブルの一例を示す説明図である。 図７は、リソーステーブルの一例を示す説明図である。 図８は、マッピングテーブルの一例を示す説明図である。 図９は、秘匿化判定パターンの一例を示す説明図である。 図１０は、図９に示した秘匿化判定パターンに基づく秘匿化判定処理の一例を示す説明図である。 図１１は、秘匿化装置が実行する子セッション生成処理の一例を示すフローチャートである。 図１２は、図１１に示したダミー生成処理（ステップＳ１１０５）の一例を示すフローチャートである。 図１３は、画面表示処理の一例を示すフローチャートである。 図１４は、データ更新処理の一例を示すフローチャートである。 図１５は、セッション破棄処理の一例を示すフローチャートである。 図１６は、図１５に示したダミー破棄処理（ステップＳ１５０４、Ｓ１５０８）の一例を示すフローチャートである。

以下、本実施例にかかる秘匿化装置について説明する。なお、以下の説明において、「秘匿化」とは、リソースとなる情報のうち一部または全部の項目の属性を維持したまま当該項目の値を文字以外の意味のない図形（たとえば、黒塗り）や記号に書き換えたりするほか、当該項目の属性を維持したまま意味のある別のデータに書き換えることを含む。すなわち、データの保護が必要なユーザに対しては、架空のデータとして表示される。また、「リソース」とは、たとえば、顧客情報のような、秘匿化装置と通信可能な業務用端末が秘匿化装置から参照可能な情報である。

＜秘匿化システムのハードウェア構成例＞
図１は、秘匿化システムのハードウェア構成例を示すブロック図である。秘匿化システム１００は、管理対象プラットフォーム１０１と、秘匿化装置１０２と、複数（図１では、例として２台）の業務用端末１０３Ａ、１０３Ｂ（業務用端末１０３Ａ、１０３Ｂを区別しない場合、単に業務用端末１０３と表記。）と、を有する。

管理対象プラットフォーム１０１および秘匿化装置１０２は、たとえば、管理用ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０４を介して相互に通信可能に接続される。秘匿化装置１０２および業務用端末１０３は、たとえば、業務用ＬＡＮ１０５を介して相互に通信可能に接続される。管理用ＬＡＮ１０４および業務用ＬＡＮ１０５は、インターネットやＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）でもよい。

管理対象プラットフォーム１０１は、秘匿化装置１０２が管理するプラットフォームである。管理対象プラットフォーム１０１は、通信インタフェース１１０を有する。通信インタフェース１１０は、管理用ＬＡＮ１０４を介して、秘匿化装置１０２の通信インタフェース１２１と通信可能に接続される。

秘匿化装置１０２は、業務用端末１０３に対してＷｅｂサーバとして機能する。具体的には、たとえば、秘匿化装置１０２は、通信インタフェース１２１と、通信インタフェース１２２と、プロセッサ１２３と、メモリ１２４と、を有する。通信インタフェース１２１は、管理用ＬＡＮ１０４を介して、管理対象プラットフォーム１０１の通信インタフェース１１０と通信可能に接続される。通信インタフェース１２２は、業務用ＬＡＮ１０５を介して、業務用端末１０３と通信可能に接続される。

プロセッサ１２３は、秘匿化装置１０２を制御する。メモリ１２４は、プロセッサ１２３の作業エリアとなる。また、メモリ１２４は、各種プログラムやデータを記憶する非一時的なまたは一時的な記録媒体である。メモリ１２４は、たとえば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、フラッシュメモリなどの記憶デバイスで構成される。

メモリ１２４は、通信プログラム１５０と、リソース制御プログラム１６０と、データベース１７０と、を記憶する。データベース１７０は、管理用ＬＡＮ１０４または業務用ＬＡＮ１０５に接続された不図示のデータベースサーバ内に保存されてもよい。

通信プログラム１５０において、リクエスト受信部１５１およびレスポンス送信部１５２は、具体的には、たとえば、通信プログラム１５０をプロセッサ１２３に実行させることにより実現される機能である。リクエスト受信部１５１は、業務用端末１０３からリクエストを受信する。レスポンス送信部１５２は、リクエストの送信元の業務用端末１０３にレスポンスを送信する。

リソース制御プログラム１６０において、リソースアクセス制御部１６１、ダミー生成部１６２、およびデータ更新部１６３は、具体的には、たとえば、リソース制御プログラム１６０をプロセッサ１２３に実行させることにより実現される機能である。

リソースアクセス制御部１６１は、リソースへのアクセスを制御する。リソースとは、リソーステーブル１７３のエントリである。ダミー生成部１６２は、リソースに含まれるデータ群のうち秘匿すべきデータを秘匿化したダミーデータを生成する。データ更新部１６３は、リソースのデータ群のうち、業務用端末１０３によって変更されたデータを更新する。

データベース１７０は、セッションテーブル１７１（図５で後述）と、リソースタイプテーブル１７２（図６で後述）と、リソーステーブル１７３（図７で後述）と、マッピングテーブル１７４（図８で後述）と、を有する。

なお、図示はしないが、秘匿化装置１０２は、たとえば、キーボード、マウス、タッチパネル、テンキー、スキャナ、マイク、センサのような入力デバイスや、たとえば、ディスプレイ、プリンタ、スピーカのような出力デバイスを有してもよい。

業務用端末１０３Ａは、データ保護を必要としないユーザＵＡが使用するコンピュータである。ユーザＵＡは、たとえば、秘匿化システム１００のシステム管理者（ａｄｍｉｎ）である。業務用端末１０３Ａは、秘匿化装置１０２からのレスポンスによりＷｅｂ画面１３０Ａを表示する。

Ｗｅｂ画面１３０Ａには、ユーザＵＡが所属する事業者が取り扱う顧客情報（Ｃｕｓｔｏｍｅｒ Ｉｎｆｏ）として、ＩＤ：０ｘ０１、ランク（Ｒａｎｋ）：Ｓｉｌｖｅｒ、名前（Ｎａｍｅ）：Ｌｕｆｆｙ、郵便番号（Ｚｉｐ Ｃｏｄｅ）：１２３－４５が表示されている。

ＩＤは顧客を一意に特定する識別情報であり、「０ｘ０１」は、名前が「Ｌｕｆｆｙ」である顧客のＩＤを示す。ランクは顧客の等級であり、「Ｓｉｌｖｅｒ」は、名前が「Ｌｕｆｆｙ」である顧客の等級を示す。名前は顧客を指定する名称（たとえば、氏名やハンドル名）を示す文字列であり、「Ｌｕｆｆｙ」は、ＩＤが「０ｘ０１」である顧客の名称である。郵便番号は、郵便物の配送のために顧客の居住地を含む地域を分類した数字列である。「１２３－４５」は、名前が「Ｌｕｆｆｙ」である顧客の郵便番号である。ユーザＵＡは、データ保護を必要としない者であるため、顧客情報が秘匿化されることなくＷｅｂ画面１３０Ａに表示される。

業務用端末１０３Ｂは、データ保護を必要とするユーザＵＢが使用するコンピュータである。ユーザＵＢは、たとえば、ユーザＵＡの協業先のエンジニアであり、ユーザＵＡから見ると「ｇｕｅｓｔ」という立場になる。業務用端末１０３Ｂは、Ｗｅｂ画面１３０Ｂを表示する。Ｗｅｂ画面１３０Ｂには、ユーザＵＡが所属する事業者が取り扱う顧客情報として、ＩＤ：０ｘ０１、ランク：Ｓｉｌｖｅｒ、名前：Ｓｔｒａｗｈａｔ、郵便番号：０００－００が表示されている。

ユーザＵＢは、データ保護を必要とする者であるため、顧客情報の一部である名前が「Ｌｕｆｆｙ」から「Ｓｔｒａｗｈａｔ」に秘匿化され、郵便番号が「１２３－４５」から「０００－００」に秘匿化されて、Ｗｅｂ画面１３０Ａと同時にＷｅｂ画面１３０Ｂに表示される。なお、以下の説明で、Ｗｅｂ画面１３０Ａ、１３０Ｂを区別しない場合は、単に、Ｗｅｂ画面１３０と表記する。

＜データ参照例＞
図２は、秘匿化システム１００におけるデータ参照例を示す説明図である。図２では、図１に示した顧客情報をＷｅｂ画面１３０Ａ、Ｗｅｂ画面１３０Ｂに表示して、ユーザＵＡ、ＵＢが参照する例を示す。データベース１７０には、表示対象となるリソースがマスタデータ２０１として記憶されている。マスタデータ２０１は、ＩＤ：０ｘ０１、ランク：Ｓｉｌｖｅｒ、名前：Ｌｕｆｆｙ、郵便番号：１２３－４５を有する顧客情報であり、リソーステーブル１７３のエントリとして登録されている。

ダミー生成部１６２は、マスタデータ２０１からダミーデータ２０２を生成する。ダミーデータ２０２は、マスタデータ２０１に含まれているＩＤ：０ｘ０１、ランク：Ｓｉｌｖｅｒと、マスタデータ２０１に含まれている名前「Ｌｕｆｆｙ」を「Ｓｔｒａｗｈａｔ」に秘匿化し、郵便番号「１２３－４５」を「０００－００」に秘匿化した顧客情報である。ダミーデータ２０２もリソーステーブル１７３のエントリとして、マスタデータ２０１とは別に登録されている。

マスタデータ２０１のうちどのデータを秘匿化するかについては、そのデータの属性やユーザＵＢの属性によって決定される（図９および図１０で後述）。秘匿化装置１０２は、マスタデータ２０１を業務用端末１０３Ａに送信するとともに、ダミーデータ２０２を業務用端末１０３Ｂに送信することにより、業務用端末１０３Ａにはマスタデータ２０１がＷｅｂ画面１３０Ａに表示され、業務用端末１０３Ｂにはダミーデータ２０２がＷｅｂ画面１３０Ａと同時にＷｅｂ画面１３０Ｂに表示される。

たとえば、ユーザＵＡ，ＵＢが参加するＷｅｂ会議において顧客情報を参照する場合、ユーザＵＡがユーザＵＢに見せたくないデータ（顧客の名前「Ｌｕｆｆｙ」および郵便番号「１２３－４５」）があったとしても、ユーザＵＢの参照時には顧客の名前「Ｌｕｆｆｙ」および郵便番号「１２３－４５」は秘匿化されて「Ｓｔｒａｗｈａｔ」および「０００－００」に変換済みである。

このため、ユーザＵＡは、顧客の名前「Ｌｕｆｆｙ」および郵便番号「１２３－４５」の項目をＷｅｂサーバに対して修正して、ＷｅｂサーバがユーザＵＢの業務用端末１０３Ｂに送るといった手間がかからない。したがって、業務用ＬＡＮ１０５のトラフィックの混雑が低減化され、秘匿化装置１０２の負荷低減を図ることができる。

また、上記のような修正の手間がかからないため、ユーザＵＡ，ＵＢが異なるデータ保護レベルであってもリアルタイムに同じ顧客情報を参照することができる。したがって、ユーザＵＡ，ＵＢにとって利便性が高く、会議の進行の効率化を図ることができる。

＜データ更新例＞
図３は、秘匿化システム１００におけるデータ更新例１を示す説明図である。データ更新例１は、業務用端末１０３Ｂにおいてダミーデータ２０２が更新された場合のマスタデータ２０１の更新例を示す。

（１）業務用端末１０３Ｂが、ユーザＵＢの操作により、ランクが「Ｓｉｌｖｅｒ」から「Ｇｏｌｄ」に変更されると、業務用端末１０３Ｂは、ランクの変更リクエストを秘匿化装置１０２に送信する。なお、ランクは、ユーザＵＢにより変更可能なデータである。

（２）秘匿化装置１０２は、リクエスト受信部１５１により（１）の「Ｓｉｌｖｅｒ」から「Ｇｏｌｄ」へのランクの変更リクエストを受信すると、データ更新部１６３により、リソーステーブル１７３内のダミーデータ２０２のランクを「Ｓｉｌｖｅｒ」から「Ｇｏｌｄ」に変更する。

（３）秘匿化装置１０２は、データ更新部１６３により、（２）のダミーデータ２０２におけるランクの「Ｓｉｌｖｅｒ」から「Ｇｏｌｄ」への変更を、リソーステーブル１７３内のマスタデータ２０１に反映する。

（４）秘匿化装置１０２は、レスポンス送信部１５２により、（３）のランクの「Ｓｉｌｖｅｒ」から「Ｇｏｌｄ」への変更が反映されたマスタデータ２０１を、業務用端末１０３Ａに送信し、Ｗｅｂ画面１３０Ａを更新する。これにより、業務用端末１０３Ｂでの変更が即座にＷｅｂ画面１３０Ａに反映される。

このように、ユーザＵＡ、ＵＢの双方にとって秘匿化されていないデータについては、いずれか一方の変更が他方に即座に反映される。

図４は、秘匿化システム１００におけるデータ更新例２を示す説明図である。データ更新例１は、業務用端末１０３Ａにおいてマスタデータ２０１が更新された場合のダミーデータ２０２の更新例を示す。図４では、マスタデータ２０１の名前に誤記があり、その誤記を修正する場合を例に挙げる。なお、名前については、ユーザＵＡは変更する権限を有するが、ユーザＵＢは有していない。

（１）業務用端末１０３Ａが、ユーザＵＡの操作により、名前が「Ｌｕｆｙ」から「Ｌｕｆｆｙ」に変更されると、業務用端末１０３Ａは、名前の変更リクエストを秘匿化装置１０２に送信する。

（２）秘匿化装置１０２は、リクエスト受信部１５１により、（１）の「Ｌｕｆｙ」から「Ｌｕｆｆｙ」へのランクの変更リクエストを受信すると、データ更新部１６３によりリソーステーブル１７３内のマスタデータ２０１の名前を「Ｌｕｆｙ」から「Ｌｕｆｆｙ」に変更する。

（３）秘匿化装置１０２は、ダミー生成部１６２により、（２）のマスタデータ２０１における名前の「Ｌｕｆｙ」から「Ｌｕｆｆｙ」への変更を契機として、変更後の「Ｌｕｆｆｙ」に応じたダミー名として名前「Ｒｕｂｂｅｒ」を生成する。なお、ダミー名の生成は既存技術であるため詳細を割愛するが、入力データ（ここでは「Ｌｕｆｆｙ」）の文字列から変換された文字列でも、関連性のないランダマイズされた文字列でもよく、また、入力データに関連する文字列を管理対象プラットフォーム１０１やインターネット上のサイトから取得してもよい。そして、秘匿化装置１０２は、リソーステーブル１７３内のダミーデータ２０２の名前「Ｓｔｒａｗｈａｔ」からダミー名「Ｒｕｂｂｅｒ」に変更する。

（４）秘匿化装置１０２は、レスポンス送信部１５２により、（３）のダミー名「Ｒｕｂｂｅｒ」が反映されたダミーデータ２０２により、業務用端末１０３ＢのＷｅｂ画面１３０Ｂを更新する。これにより、業務用端末１０３Ａでの変更が即座にＷｅｂ画面１３０Ｂに反映される。このように、ユーザＵＢに秘匿化されているデータをユーザＵＡが変更する場合、当該変更がユーザＵＢの業務用端末１０３Ｂに即座に反映される。

なお、上記（３）において、ダミー生成部１６２は、ダミー名を生成しなくてもよい。この場合、ダミーデータ２０２の名前は「Ｓｔｒａｗｈａｔ」のままであり、Ｗｅｂ画面１３０Ｂも更新されない。これにより、業務用端末１０３Ａで名前の修正が行われたこと自体が秘匿化される。

＜データベース１７０＞
つぎに、データベース１７０に記憶されているテーブル群について具体的に説明する。

図５は、セッションテーブル１７１の一例を示す説明図である。セッションテーブル１７１は、秘匿化装置１０２と業務用端末１０３との間に確立されたセッションを管理するテーブルである。セッションテーブル１７１は、フィールドとして、セッションＩＤ（ｓｅｓｓｉｏｎ＿ｉｄ）５０１と、ユーザ名（ｕｓｅｒ）５０２と、第１秘匿化制御レベル（ａｃｌｅｖｅｌ）５０３と、親セッションＩＤ（ｐａｒｅｎｔ＿ＩＤ）５０４と、を有する。同一行における各フィールド５０１～５０４の値の組み合わせが、１つのセッションを規定するエントリとなる。

セッションＩＤ５０１は、セッションを一意に特定する識別情報である。ユーザ名５０２は、そのセッションが確立された業務用端末１０３を使用するユーザを指定する名称（たとえば、氏名やハンドル名、役職名、職種名）を示す文字列であり、ユーザの属性を示す。「ａｄｍｉｎ」はある事業者における管理者、「ｗｏｒｋｅｒ」は当該事業者における従業員、「ｇｕｅｓｔ」は当該事業者の協業先の従業員（参加者）である。

第１秘匿化制御レベル５０３は、ユーザ名５０２で特定されるユーザに対しデータの秘匿化を実行するか否かを制御するレベルである。すなわち、第１秘匿化制御レベル５０３は、ユーザに対しデータの保護の必要性の低さを示す。当該レベルの値が大きいほど、当該データの秘匿化は実行されにくくなり（データの保護の必要性が低く）、その値が小さいほど当該データの秘匿化は実行されやすくなる（データの保護の必要性が高い）。

本例では、たとえば、第１秘匿化制御レベル５０３の値が「２」のユーザ名５０２は、データの保護（秘匿化）の必要性がないユーザ属性であり、第１秘匿化制御レベル５０３の値が「０」のユーザ名５０２は、データの保護（秘匿化）の必要性があるユーザ属性であり、第１秘匿化制御レベル５０３の値が「１」のユーザ名５０２は、後述する第２秘匿化制御レベル６０４に応じて、データの保護（秘匿化）の必要性が決定されるユーザ属性である。

なお、ユーザ名５０２および第１秘匿化制御レベル５０３の組み合わせは、図示しないテーブルによりメモリ１２４内で管理されており、セッションテーブル１７１のエントリ生成時に参照される。

親セッションＩＤ５０４は、親セッションを一意に特定する識別情報である。親セッションとは、セッションＩＤ５０１で規定されるセッションを子セッションとした場合、当該子セッションの生成元となるセッションである。すなわち、親セッションＩＤ５０４は、当該生成元となるセッションのセッションＩＤ５０１である。なお、親セッションにはその親セッションは存在しないため、親セッションを規定するエントリにおける親セッションＩＤ５０４の値は、親セッションが存在しないことを示す「ｎｕｌｌ」となる。

また、秘匿化装置１０２と親セッションが確立した業務用端末１０３ＡのユーザＵＡを親ユーザと称する場合があり、秘匿化装置１０２と子セッションが確立した業務用端末１０３ＢのユーザＵＢを子ユーザと称する場合がある。

図５では、１行目のエントリは、親セッションＩＤ５０４が存在しないため親セッションを示し、２行目および３行目のエントリは、親セッションＩＤ５０４の値が１行目のエントリのセッションＩＤ５０１の値であるため、当該親セッションの子セッションを示す。なお、リソースアクセス制御部１６１は、秘匿化装置１０２または業務用端末１０３によってセッションが終了されると、当該セッションのエントリをセッションテーブル１７１から削除する（図１５で後述）。

図６は、リソースタイプテーブル１７２の一例を示す説明図である。リソースタイプテーブル１７２は、リソース内のデータの属性を規定するテーブルである。リソースは、たとえば、顧客情報のような、複数の業務用端末１０３で参照可能な情報である。

リソースタイプテーブル１７２は、フィールドとして、リソースタイプ（ｒｅｓｏｕｒｃｅ ｔｙｐｅ）６０１と、パラメータ（ｐａｒａｍ）６０２と、フォーマット（ｆｏｒｍａｔ）６０３と、第２秘匿化制御レベル（ａｃＬｅｖｅｌ）６０４と、を有する。リソースタイプ６０１の行における各フィールド６０１～６０４の値の組み合わせが、１つのリソースタイプ６０１を規定するエントリとなる。

リソースタイプ６０１は、顧客（ｃｕｓｔｏｍｅｒ）６１１のようなリソースの種別である。パラメータ６０２は、リソースタイプ６０１ごとに設けられた項目であり、リソース内のデータの属性を示す。パラメータ６０２は、たとえば、リソースタイプ６０１の値が顧客６１１の場合、図１～図４のＷｅｂ画面１３０に示したＩＤ、ランク（ｒａｎｋ）、名前（ｎａｍｅ）、郵便番号（ｚｉｐ ｃｏｄｅ）である。

フォーマット６０３は、パラメータ６０２の記述形式である。たとえば、「ｎｕｍｂｅｒ」はパラメータ６０２を数値で表す記述形式であり、「ｓｔｒｉｎｇ」はパラメータ６０２を文字列で表す記述形式である。

第２秘匿化制御レベル６０４は、リソースタイプ６０１で特定されるリソースについてデータの秘匿化を実行するか否かを制御するレベルであり、その値が大きいほど、当該データの秘匿化は実行されやすくなり、その値が小さいほど当該データの秘匿化は実行されにくくなる。

図６において、リソースタイプ６０１の値が顧客６１１のエントリについては、ＩＤ、ランク（ｒａｎｋ）、名前（ｎａｍｅ）、郵便番号（ｚｉｐ ｃｏｄｅ）という４つのパラメータ６０２を有し、各々の第２秘匿化制御レベル６０４の値は、「０」、「０」、「１」、「２」である。すなわち、ＩＤおよびランク（ｒａｎｋ）は、名前（ｎａｍｅ）と比較して秘匿化されにくく、郵便番号（ｚｉｐ ｃｏｄｅ）は、名前（ｎａｍｅ）と比較して秘匿化されやすいことを示す。

本例では、たとえば、第２秘匿化制御レベル６０４の値が「０」のパラメータ６０２は、そのデータの保護（秘匿化）の必要性がない項目属性であり、第２秘匿化制御レベル６０４の値が「２」のパラメータ６０２は、そのデータの保護（秘匿化）の必要性がある項目属性であり、第２秘匿化制御レベル６０４の値が「１」のパラメータ６０２は、第１秘匿化制御レベル５０３に応じて、データの保護（秘匿化）の必要性が決定される項目意属性である。

図７は、リソーステーブル１７３の一例を示す説明図である。リソーステーブル１７３は、リソースに関するデータを記憶するテーブルである。リソーステーブル１７３は、リソースタイプ６０１ごとに存在するが、図７では、リソースタイプ６０１の値が顧客６１１の場合のリソーステーブル１７３を例に挙げて説明する。

リソーステーブル１７３は、フィールドとして、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）７０１と、リソースタイプ６０１の値が顧客６１１の場合のパラメータ６０２であるＩＤ７０２、ランク（ｒａｎｋ）７０３、名前（ｎａｍｅ）７０４および郵便番号（ｚｉｐ ｃｏｄｅ）７０５と、を有する。ＩＤ７０２、ランク７０３、名前７０４および郵便番号７０５の各値は、パラメータ６０２の内容を示す。

同一行における各フィールド７０１～７０５の値の組み合わせが、１つのリソースである顧客情報を規定するエントリとなる。ただし、同一顧客のマスタデータ２０１およびダミーデータ２０２を区別するため、同一顧客であっても、マスタデータ２０１のエントリとダミーデータ２０２のエントリとは別々に格納される。

ＵＵＩＤ７０１は、リソースである顧客情報を一意に特定する識別情報である。ＩＤ７０２は、ＵＵＩＤ７０１で特定された顧客情報における顧客６１１を一意に特定する識別情報であり、Ｗｅｂ画面１３０のＩＤとして表示される。上述したように、同一顧客６１１であっても、マスタデータ２０１のエントリとダミーデータ２０２のエントリとは別々に格納されるため、複数のエントリに同一のＩＤ７０２の値が存在する場合がある。

ランク７０３は、ＩＤ７０２で特定された顧客６１１の等級であり、Ｗｅｂ画面１３０のＲａｎｋとして表示される。名前７０４は、ＩＤ７０２で特定された顧客６１１を指定する名称（たとえば、氏名やハンドル名）を示す文字列であり、Ｗｅｂ画面１３０のＮａｍｅとして表示される。なお、当該エントリがダミーデータ２０２であれば、名前７０４の値としてダミー名が登録される。郵便番号７０５は、郵便物の配送のためにＩＤ７０２で特定された顧客６１１の居住地を含む地域を分類した数字列であり、Ｗｅｂ画面１３０のＺｉｐ Ｃｏｄｅとして表示される。

図８は、マッピングテーブル１７４の一例を示す説明図である。マッピングテーブル１７４は、マスタデータ２０１とダミーデータ２０２との関連性を記憶するテーブルである。マッピングテーブル１７４は、フィールドとして、ソース（ｓｏｕｒｃｅ）８０１と、ターゲット（ｔａｒｇｅｔ）８０２と、関連セッションＩＤ（ｓｅｓｓｉｏｎ＿ｉｄ）８０３と、を有する。同一行における各フィールド８０１～８０３の値の組み合わせが、１つのマスタデータ２０１および１つのダミーデータ２０２の関連性を規定するエントリとなる。

ソース８０１は、マスタデータ２０１のリソースタイプ６０１およびＵＵＩＤ７０１の値の組み合わせであり、マスタデータ２０１を一意に特定する。ターゲット８０２は、ダミーデータ２０２のリソースタイプ６０１およびＵＵＩＤ７０１の値の組み合わせであり、ダミーデータ２０２を一意に特定する。

関連セッションＩＤ８０３は、ソース８０１およびターゲット８０２に関連するセッションＩＤ５０１である。具体的には、たとえば、関連セッションＩＤ８０３は、ソース８０１で特定されるマスタデータ２０１が提供される業務用端末１０３Ａからの指定により、ターゲット８０２で特定されるダミーデータ２０２が提供される業務用端末１０３Ｂのために生成された子セッションのセッションＩＤ５０１である。

なお、リソースアクセス制御部１６１は、秘匿化装置１０２または業務用端末１０３によってセッションが終了すると、当該セッションのセッションＩＤ５０１が関連セッションＩＤ８０３として登録されているエントリをマッピングテーブル１７４から削除する。

＜秘匿化判定処理例＞
図９は、秘匿化判定パターンの一例を示す説明図である。図９において、秘匿化判定パターン９００は、第１秘匿化制御レベル５０３の値と第２秘匿化制御レベル６０４の値との組み合わせと、当該組み合わせごとの秘匿化有無と、を示す。秘匿化装置１０２は、秘匿化判定パターン９００を参照して、秘匿化の判定対象となるパラメータ６０２（ＩＤ７０２、ランク７０３、名前７０４、郵便番号７０５）の値が、秘匿化されるデータである（ｍａｓｋｅｄ）か、または、秘匿化されないデータである（ｎｏｔ ｍａｓｋｅｄ）か、を判定する。

図１０は、図９に示した秘匿化判定パターン９００に基づく秘匿化判定処理の一例を示す説明図である。秘匿化判定処理テーブル１０００において、左端の列はセッションＩＤ５０１およびユーザ名５０２で、上端の行はリソースタイプ６０１が顧客６１１である。「ａｃＬｅｖｅｌ」の列は、セッションＩＤ５０１およびユーザ名５０２の組み合わせごとの第１秘匿化制御レベル５０３を示す。「ａｃＬｅｖｅｌ」の行は、ＩＤ７０２、ランク７０３、名前７０４および郵便番号７０５の第２秘匿化制御レベル６０４を示す。

図１０において、セルの各々は、セッションＩＤ５０１およびユーザ名５０２の第１秘匿化制御レベル５０３との組み合わせで特定される行と、ＩＤ７０２、ランク７０３、名前７０４および郵便番号７０５の各々の第２秘匿化制御レベル６０４で特定される列と、により特定される。各セルには、「ｍａｓｋｅｄ」（秘匿化）、または、「ｎｏｔ ｍａｓｋｅｄ」（秘匿化されない）が秘匿化判定結果として記憶されている。秘匿化装置１０２は、秘匿化判定結果を参照して、セッションＩＤ５０１およびユーザ名５０２で特定されるユーザのセッションにおいて、ＩＤ７０２、ランク７０３、名前７０４および郵便番号７０５の値を秘匿化したり、秘匿化しなかったりする。

たとえば、ユーザ名５０２が「ａｄｍｉｎ」であるユーザＵＡについてのセッション（セッションＩＤ５０１：「１ａ２ｃ３９ｂａ…」）については、第１秘匿化制御レベル５０３の値が「２」であるため、ＩＤ７０２、ランク７０３、名前７０４および郵便番号７０５の第２秘匿化制御レベル６０４の値がいずれの値であっても、ＩＤ７０２、ランク７０３、名前７０４および郵便番号７０５の値であるリソースのデータは、ユーザＵＡの業務用端末１０３ＡのＷｅｂ画面１３０Ａでは秘匿化されない（ｎｏｔ ｍａｓｋｅｄ）（図９の第１秘匿化制御レベル５０３の値が「２」の列を参照。）。

また、ユーザ名５０２が「ｗｏｒｋｅｒ」であるユーザについてのセッション（セッションＩＤ５０１：「３ｄｅ５ａｂｂ９…」）については、第１秘匿化制御レベル５０３の値が「１」であるため、ＩＤ７０２、ランク７０３、名前７０４および郵便番号７０５のうち、第２秘匿化制御レベル６０４の値が「１」以下であるＩＤ７０２、ランク７０３および名前７０４の値であるリソースのデータは、当該ユーザがユーザＵＢであれば、その業務用端末１０３のＷｅｂ画面１３０Ｂにおいて秘匿化されず（ｎｏｔ ｍａｓｋｅｄ）、第２秘匿化制御レベル６０４の値が「２」である郵便番号７０５の値であるリソースのデータは、Ｗｅｂ画面１３０において秘匿化される（ｎｏｔ ｍａｓｋｅｄ）（図９の第１秘匿化制御レベル５０３の値が「１」の列を参照。）。

また、ユーザ名５０２が「ｇｕｅｓｔ」であるユーザＵＢについてのセッション（セッションＩＤ５０１：「ｄ５６ｅａｄ７６…」）については、第１秘匿化制御レベル５０３の値が「０」であるため、ＩＤ７０２、ランク７０３、名前７０４および郵便番号７０５のうち、第２秘匿化制御レベル６０４の値が「０」であるＩＤ７０２およびランク７０３の値であるリソースのデータは、当該ユーザがユーザＵＢであれば、その業務用端末１０３ＢのＷｅｂ画面１３０Ｂにおいて秘匿化されず（ｎｏｔ ｍａｓｋｅｄ）、第２秘匿化制御レベル６０４の値が「１」以上の名前７０４および郵便番号７０５の値であるリソースのデータは、Ｗｅｂ画面１３０Ｂにおいて秘匿化される（ｎｏｔ ｍａｓｋｅｄ）（図９の第１秘匿化制御レベル５０３の値が「０」の列を参照。）。

なお、図９および図１０を用いた判定処理を秘匿化有無判定ロジックと称す。

＜子セッション生成処理＞
図１１は、秘匿化装置１０２が実行する子セッション生成処理の一例を示すフローチャートである。なお、子セッション生成処理に先立って、その親セッションとして、秘匿化装置１０２とユーザＵＡの業務用端末１０３Ａとのセッションが確立され、かつ、遮断されていないものとする。具体的には、たとえば、ユーザＵＡの操作により、業務用端末１０３Ａが秘匿化装置１０２にアクセスしてログインが完了しており、図５に示した１行目のエントリがセッションテーブル１７１に登録され、２行目以降のエントリが登録されていない状態である。

また、ユーザＵＢの業務用端末１０３Ｂは、生成される子セッションでログインするため、子セッション生成前は、ログインしていない。また、リソーステーブル１７３には、マスタデータ２０１についてのエントリが登録されており、そのダミーデータ２０２のエントリは登録されていないものとする。

まず、秘匿化装置１０２は、リソースアクセス制御部１６１により、親ユーザであるユーザＵＡが、Ｗｅｂ画面１３０Ａ上で、子セッションの第１秘匿化制御レベル５０３を指定して、子セッションを生成する（ステップＳ１１０１）。たとえば、指定された子セッションの第１秘匿化制御レベル５０３が「１」であれば、ユーザ名５０２が「ｗｏｒｋｅｒ」である業務用端末１０３と秘匿化装置１０２との間の子セッションが生成し、指定された子セッションの第１秘匿化制御レベル５０３が「０」であれば、ユーザ名５０２が「ｇｕｅｓｔ」である業務用端末１０３Ｂと秘匿化装置１０２との間の子セッションが生成される。

つぎに、秘匿化装置１０２は、データ更新部１６３により、セッションテーブル１７１に、ステップＳ１１０１生成した子セッションのエントリを追加する（ステップＳ１１０２）。たとえば、子セッションのユーザＵＢが「ｗｏｒｋｅｒ」であれば、セッションテーブル１７１の２行目のエントリが追加され、子セッションのユーザＵＢが「ｇｕｅｓｔ」であれば、セッションテーブル１７１の３行目のエントリが追加される。

つぎに、秘匿化装置１０２は、子セッションの第１秘匿化制御レベル５０３の値が「０」または「１」であるか否かを判定する（ステップＳ１１０３）。「０」および「１」のいずれでもない場合、すなわち、「２」である場合（ステップＳ１１０３：Ｎｏ）、ステップＳ１１０１で生成されたセッションは秘匿の必要がないセッションであるため、秘匿化装置１０２は、ダミーデータ２０２を生成せずに終了する。

つぎに、秘匿化装置１０２は、全リソース（リソーステーブル１７３の全エントリ）のうち未選択のリソースを選択して（ステップＳ１１０４）、選択リソースについて、ダミー生成部１６２によりダミー生成処理を実行する（ステップＳ１１０５）。ダミー生成処理（ステップＳ１１０５）は、選択リソースについてダミーデータ２０２を生成する処理であり、その詳細は図１２で後述する。

つぎに、秘匿化装置１０２は、未選択のリソースがあるか否かを判定し、未選択のリソースがあればステップＳ１１０４に処理を戻し、未選択のリソースがなければ、子セッション生成処理を終了する（ステップＳ１１０６）。

なお、図１１の例では、子セッションが生成されると、ダミー生成処理（ステップＳ１１０５）によりダミーデータ２０２を生成したが、たとえば、秘匿化装置１０２は、子セッションの生成後でＷｅｂ画面１３０Ｂにダミーデータ２０２を表示させる場合に、当該表示に先立ってダミーデータ２０２を生成してもよい。

＜ダミー生成処理（ステップＳ１１０５）＞
図１２は、図１１に示したダミー生成処理（ステップＳ１１０５）の一例を示すフローチャートである。まず、秘匿化装置１０２は、ダミー生成部１６２により、リソースタイプテーブル１７２から選択リソースのパラメータ６０２を検索する（ステップＳ１２０１）。選択リソースのリソースタイプ６０１が顧客６１１である場合、パラメータ６０２としてＩＤ７０２、ランク７０３、名前７０４、および郵便番号７０５が検索される。

つぎに、秘匿化装置１０２は、ダミー生成部１６２により、検索されたパラメータ群のうち未選択のパラメータ６０２を選択し（ステップＳ１２０２）、選択したパラメータ６０２についてステップＳ１２０３～Ｓ１２０６を実行する。そして、秘匿化装置１０２は、ダミー生成部１６２により、未選択のパラメータ６０２があるか否かを判定し、未選択のパラメータ６０２があればステップＳ１２０２に処理を戻し、未選択のパラメータ６０２がなければ、ステップＳ１２０８に移行する（ステップＳ１２０７）。

ステップＳ１２０３では、秘匿化装置１０２は、ダミー生成部１６２により、図９および図１０に示した秘匿有無判定ロジックに基づいて、選択リソースにおける選択パラメータ６０２（７０２～７０５）の値の秘匿有無を判定する（ステップＳ１２０３）。たとえば、子セッションのユーザＵＢが「ｗｏｒｋｅｒ」であり、選択パラメータ６０２がＩＤ７０２、ランク７０３、名前７０４のいずれかであれば秘匿化すべきでないと判定し、郵便番号７０５であれば秘匿化すべきと判定する。

選択リソースにおける選択パラメータ６０２（７０２～７０５）の値について秘匿化すべきと判定された場合（ステップＳ１２０４：Ｙｅｓ）、秘匿化装置１０２は、ダミー生成部１６２により、秘匿化すべきと判定された選択パラメータ６０２（７０２～７０５）についてダミーのパラメータ値、すなわち、ダミーデータを生成して保持し、ステップＳ１２０７に移行する。

一方、選択リソースにおける選択パラメータ６０２（７０２～７０５）の値について秘匿化すべきでないと判定された場合（ステップＳ１２０４：Ｎｏ）、秘匿化装置１０２は、ダミー生成部１６２により、秘匿化すべきでないと判定された選択パラメータ６０２（７０２～７０５）のパラメータ値を保持し、ステップＳ１２０７に移行する。

ステップＳ１２０７において、未選択のパラメータ６０２がない場合、秘匿化装置１０２は、データ更新部１６３により、選択リソースについてステップＳ１２０５、Ｓ１２０６で保持されたパラメータの値を集約して、リソーステーブル１７３にダミーデータ２０２の新規エントリとして追加する（ステップＳ１２０８）。

そして、秘匿化装置１０２は、データ更新部１６３により、マスタデータ２０１のリソースタイプ６０１およびＵＵＩＤ７０１の値の組み合わせによりソース８０１を生成し、ダミーデータ２０２のリソースタイプ６０１およびＵＵＩＤ７０１の値の組み合わせによりターゲット８０２を生成し、関連セッションＩＤ８０３を子セッションのセッションＩＤ５０１として特定する。

そして、秘匿化装置１０２は、データ更新部１６３により、生成したソース８０１、ターゲット８０２および特定した関連セッションＩＤ８０３の値の組み合わせをマッピングテーブル１７４の新規エントリとして登録する（ステップＳ１２０９）。これにより、秘匿化装置１０２は、ダミー生成処理（ステップＳ１１０５）を終了し、図１１のステップＳ１１０６に移行する。

＜画面表示処理＞
つぎに、画面表示処理について説明する。画面表示処理は、秘匿化装置１０２が、業務用端末１０３にリソースのデータを出力し、Ｗｅｂ画面１３０に表示させるという出力処理である。具体的には、たとえば、画面表示処理は、秘匿化装置１０２が、Ｗｅｂ画面１３０に顧客情報がまだ表示されていない状態において、図２のように、顧客情報を表示させる処理を実行する。

図１３は、画面表示処理の一例を示すフローチャートである。秘匿化装置１０２は、業務用端末１０３からの表示データ要求をリクエスト受信部１５１で受信して、リソースアクセス制御部１６１に表示対象リソースのデータを要求する（ステップＳ１３０１）。

表示データ要求には、その業務用端末１０３と秘匿化装置１０２との間で確立したセッションのセッションＩＤ５０１が必要である。表示データ要求は、業務用端末１０３のユーザの操作をトリガにして、秘匿化装置１０２に送信される。また、表示データ要求は、一定時間間隔で、業務用端末１０３から秘匿化装置１０２に繰り替えし送信されてもよい。

表示対象リソースとは、たとえば、リソーステーブル１７３の全エントリにおけるＩＤ７０２～郵便番号７０５の値のうち、表示対象として指定されたエントリにおけるＩＤ７０２～郵便番号７０５の値である。具体的には、たとえば、リソーステーブル１７３の全エントリにおけるＩＤ７０２～郵便番号７０５でもよく、業務用端末１０３からの表示データ要求（たとえば、ユーザによって任意に指定されたＩＤ７０２の値のエントリ）に応じたエントリにおけるＩＤ７０２～郵便番号７０５でもよい。

つぎに、秘匿化装置１０２は、リソースアクセス制御部１６１により、表示対象リソースのうち未選択の表示対象リソースを選択し（ステップＳ１３０２）、選択した表示対象リソースについて、ステップＳ１３０３～Ｓ１３０６を実行する。そして、秘匿化装置１０２は、リソースアクセス制御部１６１により、未選択の表示対象リソースがあるか否かを判定し、未選択の表示対象リソースがあればステップＳ１３０２に処理を戻し、未選択の表示対象リソースがなければ、ステップＳ１３０８に移行する（ステップＳ１３０７）。

ステップＳ１３０３では、秘匿化装置１０２は、リソースアクセス制御部１６１により、表示データ要求に含まれるセッションＩＤ５０１の値をマッピングテーブル１７４の関連セッションＩＤ８０３から検索する（ステップＳ１３０３）。

表示データ要求に含まれるセッションＩＤ５０１に一致する値が関連セッションＩＤ８０３に存在する場合とは（ステップＳ１３０４：Ｙｅｓ）、表示データ要求に含まれるセッションＩＤ５０１が、子セッションのセッションＩＤ５０１である場合である。すなわち、子セッションを使用しログインした業務用端末１０３からの表示データ要求には、関連セッションＩＤ８０３が含まれている。したがって、秘匿化装置１０２は、リソースアクセス制御部１６１により、表示データ要求に含まれるセッションＩＤ５０１に一致した関連セッションＩＤ８０３のエントリにおけるターゲット８０２（ダミーデータ２０２のリソースタイプ６０１およびＵＵＩＤ７０１の値の組み合わせ）を取得する。

そして、秘匿化装置１０２は、リソースアクセス制御部１６１により、当該ダミーデータ２０２のリソースタイプ６０１についてのリソーステーブル１７３から、ダミーデータ２０２のＵＵＩＤ７０１のエントリのデータ（ＩＤ７０２～郵便番号７０５の値）を取得する。そして、秘匿化装置１０２は、当該取得したデータをレスポンス送信部１５２に出力し、ステップＳ１２０７に移行する。

一方、表示データ要求に含まれるセッションＩＤ５０１に一致する値が関連セッションＩＤ８０３に存在しない場合とは（ステップＳ１３０４：Ｎｏ）、表示データ要求に含まれるセッションＩＤ５０１が、親セッションのセッションＩＤ５０１である場合である。すなわち、親セッションが生成された業務用端末１０３Ａからの表示データ要求には、関連セッションＩＤ８０３が含まれていない。したがって、秘匿化装置１０２は、リソースアクセス制御部１６１により、ステップＳ１３０２で選択した表示対象リソースのエントリにおけるＩＤ７０２～郵便番号７０５の値を表示対象リソースのデータとしてリソーステーブル１７３から取得する。そして、秘匿化装置１０２は、当該取得したデータをレスポンス送信部１５２に出力し、ステップＳ１２０７に移行する。

ステップＳ１３０７において、未選択の表示対象リソースがない場合、秘匿化装置１０２は、レスポンス送信部１５２により、ステップＳ１３０５、１３０６で取得したデータを画面表示データとして、表示データ要求の出力元の業務用端末に送信する（ステップＳ１３０８）。これにより、秘匿化装置１０２は、画面表示処理を終了する。

この画面表示処理により、たとえば、業務用端末１０３Ａにおいて、Ｗｅｂ画面１３０Ａに図２に示したような顧客情報が表示され（名前が「Ｌｕｆｆｙ」）、業務用端末１０３Ｂにおいて、Ｗｅｂ画面１３０Ｂに図２に示したような顧客情報が表示される（名前が「Ｓｔｒａｗｈａｔ」）。

＜データ更新処理＞
つぎに、データ更新処理について説明する。データ更新処理は、秘匿化装置１０２が、業務用端末１０３からのデータの変更により、当該データを更新し、図３および図４に示したように、他の業務用端末１０３のＷｅｂ画面１３０に反映する処理である。

図３の例に挙げると、データ更新処理の前提として、業務用端末１０３Ａには、リソースのデータとして、マスタデータ２０１の顧客情報がＷｅｂ画面１３０Ａに表示されており、業務用端末１０３Ｂには、リソースのデータとして、ダミーデータ２０２の顧客情報がＷｅｂ画面１３０Ｂに表示されている。

図１４は、データ更新処理の一例を示すフローチャートである。まず、秘匿化装置１０２は、業務用端末１０３のＷｅｂ画面１３０からのデータ変更要求を受け付ける（ステップＳ１４０１）。具体的には、たとえば、図３に示したように、ユーザＵＢの操作により業務用端末１０３ＢのＷｅｂ画面１３０Ｂにおいて、ランクが「Ｓｉｌｖｅｒ」から「Ｇｏｌｄ」に変更されると、秘匿化装置１０２は、リクエスト受信部１５１により、ダミーデータ２０２の変更要求を受け付ける。

データ変更要求には、顧客情報としてＷｅｂ画面１３０に表示されている変更対象リソースと変更対象パラメータと変更後の値が必要である。上記の例では、変更対象リソースは、Ｗｅｂ画面１３０Ｂに表示されているダミーデータ２０２の顧客情報であり、具体的には、たとえば、図７に示したリソーステーブル１７３のＵＵＩＤ７０１が「０ｘ０Ａ０１」、ＩＤ７０２が「０ｘ０１」、ランク７０３が「Ｓｉｌｖｅｒ」、名前７０４が「Ｓｔｒａｗｈａｔ」、郵便番号７０５が「０００－００」のエントリである。また、変更対象パラメータは、ユーザＵＢが操作したランク７０３である。変更後の値は、ユーザＵＢが「Ｓｉｌｖｅｒ」から変更した「Ｇｏｌｄ」の文字列である。

つぎに、秘匿化装置１０２は、リソースアクセス制御部１６１により、変更対象リソースのＩＤ７０１でマッピングテーブル１７４のターゲット８０２を検索し、検索結果に基づいて変更対象リソースがマスタデータ２０１であるかダミーデータ２０２であるかを判定する（ステップＳ１４０２）。具体的には、たとえば、変更対象リソースに含まれているＵＵＩＤ７０１の値がターゲット８０２に存在しなければ、変更対象リソースはマスタデータ２０１であり、ターゲット８０２に存在すれば、変更対象リソースは、ダミーデータ２０２である。

上記の例では、変更対象リソースのＵＵＩＤ７０１である「０ｘ０Ａ０１」が、マッピングテーブル１７４の一行目のエントリのターゲット８０２に存在するため、変更対象リソースは、ダミーデータ２０２である。

つぎに、秘匿化装置１０２は、リソースアクセス制御部１６１により、変更対象リソースがマスタデータ２０１であれば（ステップＳ１４０３：マスタ）、ステップＳ１４０５に移行する。一方、ダミーデータ２０２であれば（ステップＳ１４０３：ダミー）、秘匿化装置１０２は、変更対象リソースのＵＵＩＤ７０１の値がターゲット８０２に存在するエントリのソース８０１からマスタデータ２０１のＵＵＩＤ７０１を特定し（ステップＳ１４０４）、ステップＳ１４０５に移行する。上記の例では、マスタデータ２０１のＵＵＩＤ７０１として「０ｘ０００１」が特定される。

ステップＳ１４０５では、秘匿化装置１０２は、リソースアクセス制御部１６１により、マッピングテーブル１７４のソース８０１がステップＳ１４０２またはＳ１４０４において特定されたマスタデータ２０１のＵＵＩＤ７０１の値であるエントリを特定し、当該特定したエントリのターゲット８０２からダミーデータ２０２のＵＵＩＤ７０１を特定し、ダミーデータ２０２のＵＵＩＤ７０１の一覧（以下、ダミー一覧）を作成する（ステップＳ１４０５）。

上記の例では、マスタデータ２０１のＵＵＩＤ７０１が「０ｘ０００１」であるため、ソース８０１の値が「０ｘ０００１」であるエントリのターゲット８０２の値「０ｘ０Ａ０１」が、ダミー一覧に追加される。このほかにも、ソース８０１の値が「０ｘ０００１」であるエントリのターゲット８０２の値がマッピングテーブル１７４に存在すれば、ダミー一覧に追加される。なお、ダミー一覧内のＵＵＩＤ７０１を「ダミーＵＵＩＤ７０１」と称す。

つぎに、秘匿化装置１０２は、データ更新部１６３により、ダミー一覧から未選択のダミーＵＵＩＤ７０１を選択する（ステップＳ１４０６）。

つぎに、秘匿化装置１０２は、データ更新部１６３により、選択したダミーＵＵＩＤ７０１の値が存在するエントリをダミーデータ２０２としてリソーステーブル１７３から特定し、特定したエントリにおいて変更対象パラメータの値を、変更後の値に更新して（ステップＳ１４０７）、ステップＳ１４０８に移行する。

上記の例では、リソーステーブル１７３においてダミーＵＵＩＤ７０１の値が「０ｘ０Ａ０１」のエントリが特定される。データ変更要求内の変更対象パラメータはランク７０３であるため、当該特定されたエントリのランク７０３の値「Ｓｉｌｖｅｒ」が、データ変更要求内の変更後の値「Ｇｏｌｄ」に更新される。

つぎに、秘匿化装置１０２は、データ更新部１６３により、ダミー一覧に未選択のダミーＵＵＩＤ７０１があるか否かを判定し、未選択のダミーＵＵＩＤ７０１があれば、ステップＳ１４０６に処理を戻し、なければステップＳ１４０９に移行する（ステップＳ１４０８）。

つぎに、秘匿化装置１０２は、データ更新部１６３により、ステップＳ１４０２またはＳ１４０４において特定されたマスタデータ２０１のＵＵＩＤ７０１の値であるエントリをリソーステーブル１７３から特定し、特定したエントリにおいて変更対象パラメータの値を、変更後の値に更新する（ステップＳ１４０９）。このあと、図１２に示した画像表示処理により、データ変更要求を送信していない業務用端末１０３のＷｅｂ画面１３０に、ステップＳ１４０７およびステップＳ１４０９の更新後のデータが表示され、データ更新処理が終了する。

上記の例では、Ｓ１４０９のデータ更新により、図３に示したように、業務用端末１０３ＡのＷｅｂ画面１３０Ａにおいて、Ｒａｎｋが「Ｓｉｌｖｅｒ」から「Ｇｏｌｄ」に変更される。

＜セッション破棄処理＞
つぎに、セッション破棄処理について説明する。セッション破棄処理とは、秘匿化装置１０２がセッションを破棄する処理である。

図１５は、セッション破棄処理の一例を示すフローチャートである。まず、秘匿化装置１０２は、セッション破棄指示を受け付ける（ステップＳ１５０１）。セッション破棄指示は、ユーザの操作により業務用端末１０３においてログアウトボタンが押下されることで、業務用端末１０３から秘匿化装置１０２に送信され、リクエスト受信部１５１が受信する。また、秘匿化装置１０２内部においてセッション確立から、あらかじめ設定された当該セッションの有効期限が経過すると、リソースアクセス制御部１６１がセッション破棄指示を受け付ける。セッション破棄指示には、破棄対象となるセッション（以下、破棄対象セッション）のセッションＩＤ５０１（以下、破棄対象セッションＩＤ５０１）が含まれる。

つぎに、秘匿化装置１０２は、リソースアクセス制御部１６１により、セッションテーブル１７１から、破棄対象セッションＩＤ５０１が親セッション５０４であるエントリを検索する（ステップＳ１５０２）。

検索されたエントリにおいて、破棄対象セッションＩＤ５０１が親セッションＩＤ５０４として登録されていない場合（ステップＳ１５０３：Ｎｏ）、破棄対象セッションＩＤ５０１は、セッションＩＤ５０１にのみ登録されていることになる。したがって、破棄対象セッションは、子セッションである。この場合、秘匿化装置１０２は、データ更新部１６３により、破棄対象セッションである子セッションについて、ダミー破棄処理を実行する（ステップＳ１５０４）。ダミー破棄処理（ステップＳ１５０４）については、図１６で後述する。

そして、秘匿化装置１０２は、データ更新部１６３により、セッションテーブル１７１から破棄対象セッション（子セッション）のエントリを削除する（ステップＳ１５０５）。

また、ステップＳ１５０３で、検索されたエントリにおいて、破棄対象セッションＩＤ５０１が親セッションＩＤ５０４として登録されている場合（ステップＳ１５０３：Ｙｅｓ）、破棄対象セッションは、親セッションである。したがって、秘匿化装置１０２は、リソースアクセス制御部１６１により、検索されたエントリの親セッションＩＤ５０４を参照して、親セッションである破棄対象セッションについて子セッションＩＤを収集し、子セッション一覧を作成する（ステップＳ１５０６）。

つぎに、秘匿化装置１０２は、データ更新部１６３により、未選択の子セッションＩＤを選択し（ステップＳ１５０７）、選択した子セッションＩＤについて、ダミー破棄処理を実行する（ステップＳ１５０８）。ダミー破棄処理（ステップＳ１５０８）は、ダミー破棄処理（ステップＳ１５０４）と同一処理であり、図１６で後述する。そして、秘匿化装置１０２は、データ更新部１６３により、セッションテーブル１７１から選択子セッションＩＤのエントリを削除する（ステップＳ１５０９）。

このあと、秘匿化装置１０２は、データ更新部１６３により、子セッション一覧に未選択の子セッションＩＤがあるか否かを判定し、未選択の子セッションＩＤがあれば、ステップＳ１５０７に処理を戻し、なければステップＳ１５１１に移行する（ステップＳ１５１０）。

そして、秘匿化装置１０２は、データ更新部１６３により、セッションテーブル１７１から破棄対象セッション（親セッション）のエントリを削除する（ステップＳ１５０５）。これにより、秘匿化装置１０２は、セッション破棄処理を終了する。

＜ダミー破棄処理＞
図１６は、図１５に示したダミー破棄処理（ステップＳ１５０４、Ｓ１５０８）の一例を示すフローチャートである。秘匿化装置１０２は、リソースアクセス制御部１６１により、マッピングテーブル１７４から、関連セッションＩＤ８０３が該当セッションＩＤ（ステップＳ１５０４であれば子セッションのセッションＩＤ、ステップＳ１５０８であれば親セッションのセッションＩＤ）であるエントリを検索する（ステップＳ１６０１）。

つぎに、秘匿化装置１０２は、データ更新部１６３により、マッピングテーブル１７４から検索されたエントリのうち、未選択のエントリを選択する（ステップＳ１６０２）。

そして、秘匿化装置１０２は、データ更新部１６３により、選択エントリのターゲット８０２におけるＵＵＩＤ７０１で特定されるリソースのエントリを、リソーステーブルから削除する（ステップＳ１６０３）。また、図示していないが、秘匿化装置１０２は、データ更新部１６３により、ステップＳ１６０２で選択したエントリをマッピングテーブル１７４から削除してもよい。

このあと、秘匿化装置１０２は、データ更新部１６３により、未選択のエントリがあるか否かを判定し、未選択のエントリがあれば、ステップＳ１６０２に処理を戻し、なければ、ダミー破棄処理（ステップＳ１５０４、Ｓ１５０８）を終了する。

このように、本実施例によれば、ユーザ名５０２およびパラメータ６０２に応じて、そのユーザに秘匿すべきデータおよび秘匿すべきでないデータがどのパラメータ６０２のデータであるかが決定される。

具体的には、たとえば、第１秘匿化制御レベル５０３が低いユーザほどデータは秘匿化されやすく、第２秘匿化制御レベル６０４が高いパラメータ６０２の値であるデータほど秘匿化されやすくなる。また、Ｗｅｂ画面１３０上で変更されたデータが他の業務用端末１０３のＷｅｂ画面１３０にリアルタイムで反映される。

したがって、第１秘匿化制御レベル５０３が異なる複数のユーザ間で、目的とするリソースを、一方にはマスタデータ２０１として、他方にはダミーデータ２０２として同時期にＷｅｂ画面１３０に表示することが可能にある。

これにより、第１秘匿化制御レベル５０３が異なるユーザ間での同時作業が実現可能になる。また、スクリーンショットや擬似環境構築など、コストとストレスがかかる作業負担が軽減される。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。たとえば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加、削除、または置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、たとえば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、又は、ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）カード、ＳＤカード、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

１００ 秘匿化システム
１０２ 秘匿化装置
１０３ 業務用端末
１２３ プロセッサ
１２４ メモリ
１５１ リクエスト受信部
１５２ レスポンス送信部
１６１ リソースアクセス制御部
１６２ ダミー生成部
１６３ データ更新部
１７０ データベース
１７１ セッションテーブル
１７２ リソースタイプテーブル
１７３ リソーステーブル
１７４ マッピングテーブル
２０１ マスタデータ
２０２ ダミーデータ
５０２ ユーザ名
５０３ 第１秘匿化制御レベル
６０１ リソースタイプ
６０２ パラメータ
６０４ 第２秘匿化制御レベル
９００ 秘匿化判定パターン
１０００ 秘匿化判定処理テーブル

Claims (15)

1. プログラムを実行するプロセッサと、前記プログラムを記憶する記憶デバイスと、を有する秘匿化装置であって、
   前記プロセッサは、
   １以上の項目と当該項目の内容を示すデータとを有するリソースについて、ユーザの属性および前記項目の属性に基づいて前記データの秘匿化を前記ユーザごとに制御する秘匿化処理と、
   前記ユーザごとに前記秘匿化処理が実行された秘匿化結果に基づく前記リソースを、前記ユーザごとの端末に出力する第１出力処理と、
   を実行することを特徴とする秘匿化装置。
2. 請求項１に記載の秘匿化装置であって、
   前記第１出力処理では、前記プロセッサは、前記ユーザの属性が前記データの保護を必要としないことを示す第１ユーザ属性である場合、前記データが秘匿化されていない前記リソースを前記端末に出力する、
   ことを特徴とする秘匿化装置。
3. 請求項１に記載の秘匿化装置であって、
   前記第１出力処理では、前記プロセッサは、前記ユーザの属性が前記データの保護を必要としないことを示す第１ユーザ属性でない場合、前記項目の属性に関する前記データの秘匿化結果に基づく前記リソースを前記端末に出力する、
   ことを特徴とする秘匿化装置。
4. 請求項３に記載の秘匿化装置であって、
   前記第１出力処理では、前記プロセッサは、前記項目の属性が前記データの保護を必要としないことを示す第１項目属性である場合、前記データが秘匿化されていない前記リソースを前記端末に出力する、
   ことを特徴とする秘匿化装置。
5. 請求項３に記載の秘匿化装置であって、
   前記第１出力処理では、前記プロセッサは、前記項目の属性が前記項目の属性が前記データの保護を必要としないことを示す第１項目属性でない場合、前記ユーザの属性および前記項目の属性に関する前記データの秘匿化結果に基づく前記リソースを前記端末に出力する、
   ことを特徴とする秘匿化装置。
6. 請求項５に記載の秘匿化装置であって、
   前記第１出力処理では、前記プロセッサは、前記ユーザの属性が前記データの保護を必要とすることを示す第２ユーザ属性である場合、前記データが秘匿化された前記リソースを前記端末に出力する、
   ことを特徴とする秘匿化装置。
7. 請求項５に記載の秘匿化装置であって、
   前記第１出力処理では、前記プロセッサは、前記項目の属性が前記データの保護を必要とすることを示す第２項目属性である場合、前記データが秘匿化された前記リソースを前記端末に出力する、
   ことを特徴とする秘匿化装置。
8. 請求項５に記載の秘匿化装置であって、
   前記第１出力処理では、前記プロセッサは、前記ユーザの属性が前記データの保護を必要とすることを示す第２ユーザ属性でなく、かつ、前記項目の属性が前記データの保護を必要とすることを示す第２項目属性でない場合、前記データが秘匿化されていない前記リソースを前記端末に出力する、
   ことを特徴とする秘匿化装置。
9. 請求項２に記載の秘匿化装置であって、
   前記プロセッサは、
   前記第１ユーザ属性のユーザの端末と前記秘匿化装置との間にセッションが確立している場合、前記第１ユーザ属性ではない他のユーザの端末と前記秘匿化装置との間に前記セッションに関連する子セッションを生成する生成処理を実行し、
   前記第１出力処理では、前記プロセッサは、前記第１ユーザ属性のユーザの端末に、前記リソースを第１リソースとして出力するとともに、前記子セッションが生成された前記他のユーザの端末に、前記秘匿化処理を実行した場合の秘匿化結果に基づく前記リソースを第２リソースとして出力する、
   ことを特徴とする秘匿化装置。
10. 請求項９に記載の秘匿化装置であって、
    前記第１出力処理では、前記プロセッサは、前記他のユーザの属性が前記データの保護を必要とすることを示す第２ユーザ属性である場合、前記項目の属性が前記データの保護を必要としないことを示す第１項目属性であるデータについては秘匿化されておらず、かつ、前記項目の属性が前記第１項目属性でないデータについては秘匿化された前記リソースを、前記他の端末に出力する、
    ことを特徴とする秘匿化装置。
11. 請求項９に記載の秘匿化装置であって、
    前記第１出力処理では、前記プロセッサは、前記他のユーザの属性が前記第１ユーザ属性および第２ユーザ属性のいずれにも該当しないユーザ属性である場合、前記項目の属性が前記データの保護を必要としないことを示す第１項目属性であるデータについては秘匿化されておらず、前記項目の属性が前記データの保護を必要とする第２項目属性であるデータについては秘匿化されており、かつ、前記項目の属性が前記第１項目属性および前記第２項目属性のいずれにも該当しない項目属性であるデータについては秘匿化された前記リソースを、前記他の端末に出力する、
    ことを特徴とする秘匿化装置。
12. 請求項９に記載の秘匿化装置であって、
    前記プロセッサは、
    前記他の端末において前記データが変更された場合、前記データが変更された変更対象項目および変更後のデータに基づいて、前記第１リソースおよび前記第２リソースを更新する更新処理と、
    前記更新処理による更新後の前記第１リソースを、前記第１ユーザ属性のユーザの端末に出力する第２出力処理と、
    を実行することを特徴とする秘匿化装置。
13. 請求項９に記載の秘匿化装置であって、
    前記プロセッサは、
    前記第１ユーザ属性のユーザの端末において前記データが変更された場合、前記データが変更された変更対象項目および変更後のデータに基づいて、前記第１リソースおよび前記第２リソースを更新する更新処理と、
    前記更新処理による更新後の前記第２リソースを、前記他の端末に出力する第２出力処理と、
    を実行することを特徴とする秘匿化装置。
14. プログラムを実行するプロセッサと、前記プログラムを記憶する記憶デバイスと、を有する秘匿化装置が実行する秘匿化方法であって、
    前記プロセッサは、
    １以上の項目と当該項目の内容を示すデータとを有するリソースについて、ユーザの属性および前記項目の属性に基づいて前記データの秘匿化を前記ユーザごとに制御する秘匿化処理と、
    前記ユーザごとに前記秘匿化処理が実行された秘匿化結果に基づく前記リソースを、前記ユーザごとの端末に出力する第１出力処理と、
    を実行することを特徴とする秘匿化方法。
15. プロセッサに、
    １以上の項目と当該項目の内容を示すデータとを有するリソースについて、ユーザの属性および前記項目の属性に基づいて前記データの秘匿化を前記ユーザごとに制御する秘匿化処理と、
    前記ユーザごとに前記秘匿化処理が実行された秘匿化結果に基づく前記リソースを、前記ユーザごとの端末に出力する第１出力処理と、
    を実行させることを特徴とする秘匿化プログラム。

Images