機微データを扱っている企業必見！参照制約を維持しながらデータマスキング！

目次

1. データマスキングとは？
2. オンプレDBからSaaSへのデータコピー
3. フロー作成
4. 実行結果
5. 【Appendix】NGケース「再現性：いいえ」

1.データマスキングとは？

データマスキングとは、IIJクラウドデータプラットフォームサービスの内「クラウドデータハブ」の機能の1つで、データソース間でのデータ連携の際に、事前に設定したルールにもとづいて値を匿名化することで、機微情報などを安全に扱える機能です。

例えば次のケースにおいて、データマスキングは有用な機能となっています。

• 本番環境のデータをテスト環境で利用したいが、個人情報はテスト環境に格納したくない
• 本番環境のデータの論理的特性を維持しつつ、テスト環境でテストデータを生成したい
• オンプレミスとクラウドとのデータ連携を行いたいが、一部の機微情報はオンプレミス上にのみ存在させたい

また、「値をすべて♯に置換する」や「ランダムな値に置換する」などの一般的なマスキングルール以外にも様々なルールを設定できることから、システムの特性やセキュリティポリシーに応じた匿名化が可能です。

※ シンプルなマスキング例はこちらの動画でも紹介しています。ぜひご覧ください。
【デモ動画#2】機微データを匿名化、安全にデータをクラウドへ連携（データマスキング機能）

本記事では「データの論理的特性の維持」にフォーカスを当て、DBで参照制約を定義しているカラムの値をランダム化してSaaSへデータをコピーした場合でも、SaaS上で参照制約が維持されてデータを正しく紐付けできる方法をご紹介します。

2.オンプレDBからSaaSへのデータコピー

次のシチュエーションにおける課題を、データマスキング機能で解決してみましょう。

A社は全国にフィットネスクラブを展開する企業であり、店舗内ではトレーニングのサービスに加え、サプリメントなどの販売も行っている。
A社では会員同意のもと、会員ごとの入退会時期やジム利用頻度、商品購入傾向などをオンプレミスのDB及びBIツールを用いてデータ分析を行い、分析結果は本社の関連部署のみ閲覧可能としている。
この度、店舗からの「サプリメントの販売促進や退会防止のため、店舗でもデータ分析結果を閲覧したい」との要望を受けてその検討を行った。
検討の結果、店舗からのDBやBIツールへのアクセスはセキュリティリスクが高いことから見送り、代替案としてDBから個人情報などの機微データはマスキングした上でSaaSにデータをコピーし、簡易的な分析結果を閲覧できる環境をSaaS上に用意する方針とした。

• DBのテーブル構成は、会員マスタテーブル「customer」と取引情報テーブル「trade」があり、「customer」と「trade」の間にはそれぞれのid列で参照制約の関係があるものとします。
  

  （クリックして拡大）

• SaaSはサイボウズ社のkintoneを導入。「会員情報」と「取引情報」のアプリがあり、「会員情報」と「取引情報」の間にはそれぞれのid列でルックアップを定義しているものとします。
  ※ ルックアップを定義することで、「取引情報のID」は「会員情報のID」に存在する値であることが必須です。
  

3.フロー作成

それでは、先ほどまでの内容を踏まえてフローを作成してみましょう。
フローの概要は次のとおりです。

1. RDBGetコンポーネント
   DBの会員マスタテーブル「customer」からデータ分析に必要なカラム「id」「年齢（age）」「性別（gender）」「入会日（date_of_registration）」「退会日（date_of_date_of_cancellation）」を指定して全レコードを取得します。
   
2. Mapperコンポーネント
   「id」は機微情報なので、「DataMask」コンポーネントを用いてランダムな値に置換し、次のコンポーネントに出力します。その他のカラムは加工せず出力します。
   
   

   Point

   「再現性」「再現キー」

   今回のケースでは、「Mapper」コンポーネント内に配置した「DataMask」コンポーネントは、プロパティで「再現性：はい」を選択する必要があります。

   「再現性：はい」を選択すると、入力値に対し指定したキー値を用いてランダム化されるため、入力値とキー値が同じであれば、フローを何度も実行した場合や異なるフローでも常に同じ出力結果が得られます。

   このように設定することで、テーブル「customer」と「trade」で同一の「id」はそれぞれランダム化されながらも同じ値が出力され、Kintone上でも整合性を保ってデータを紐づけられます。
   ※ 画像のように「再現キー」を空白とした場合はキー値に「0」が設定されたものとして処理されます。

3. kintonePutコンポーネント
   「Mapper1」コンポーネントで加工したデータをKintoneの「会員情報」アプリに出力します。
   
4. RDBGetコンポーネント
   1と同様に「trade」テーブルから全レコードを取得します。
   
5. Mapperコンポーネント
   2と同様に「id」を「再現性：はい」でランダム化し次のコンポーネントに出力します。
   
   2つのKintoneアプリをIDで紐付けることが目的なので、「DataMask」コンポーネントの「再現キー」の値は「Mapper1」の「DataMask」コンポーネントと同じ値にする必要があります。
   
6. kintonePutコンポーネント
   3と同様に「Mapper2」で加工したデータをKintoneの「取引情報」アプリに対して出力します。
   

以上でフローは完成です。
それでは実行してみましょう。

無事に正常終了しました。

4.実行結果

データ分析の前に、2つのKintoneアプリそれぞれの「ID」が同じ値でランダム化されていることを確認してみましょう。

DBで「customer」と「trade」を結合し、どの会員がいつ何を購入したのかを抽出します。

SELECT A.id,A.age,A.gender,A.date_of_registration,A.date_of_cancellation,
B.date_of_trade,B.product_name,B.unit_price,B.quantity 
FROM public.customer as A
inner join public.trade as B
on A.id = B.id
ORDER BY A.id

会員「adachiyuriko@example.jp　41歳　女性」を見ると、2023年の1月2日、1月3日、及び2月2日に商品の購入履歴があることが分かります。

（クリックして拡大）

このことを踏まえてKintoneの「会員情報」アプリを確認すると、年齢や性別などのID以外の情報から、ID「adachiyuriko@example.jp」はランダムな文字列「jlsriZbCdPVd.oqtCUKM!KL」に置換されていることが分かります。

続けて「取引情報」アプリを確認すると、ID「jlsriZbCdPVd.oqtCUKM!KL」は、DB上のID「adachiyuriko@example.jp」と同一の商品購入履歴があることが分かります。

DBのテーブル「customer」「trade」から、Kintoneアプリ「会員情報」「取引情報」それぞれに対し、機微情報をマスクしながらも参照制約を維持してデータをコピーできました。

それでは、目的であったデータ分析を行ってみます。40代～50代男性はどんな商品を購入しているのでしょうか。

（クリックして拡大）

いかがでしょうか。「データマスキング」は今回のケース以外にも様々なシーンにおいて役立つ機能になっています。ぜひご活用ください。

【Appendix】NGケース「再現性：いいえ」

おまけで、NGケースとして「DataMask」コンポーネントのプロパティで「再現性：いいえ」を選択した場合の結果を見てみましょう。

3-5の「Mapper」コンポーネント内「DataMask」コンポーネントで「再現性：いいえ」あるいは「再現性：はい」で異なる再現キーを設定して実行すると、次のようなエラーになってしまいます。

（クリックして拡大）

このID「JOF272(TbcnGSo#Ycs」は次のように「会員情報」アプリに存在しない値であることがエラーの原因です。

このように、2つの「Datamask」コンポーヘントへの入力値が同一でも、「再現性：はい」かつ再現キーを同一にしない場合は、異なる出力結果になることが分かります。
※ データ量や値によってはエラーとはならずに、「取引情報」のIDが「会員情報」の別のIDと一致してしまう場合もあります。