こんにちは、株式会社ラクスで横断的にITエンジニアの育成や、技術推進、採用促進などを行っている開発管理課に所属している鈴木( @moomooya )です。
前回は匿名化したデータがどの程度匿名化されているかの指標についてお話ししました。
今回は今回の取り組みの中で実際にデータを匿名加工する際にどのような流れで進めたのかについてお話ししていこうと思います。
連載目次
- 『全文検索 〜 Elasticsearchとデータ匿名化手法』
- 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要
- 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』
- データ匿名化 第1回：匿名化された個人情報とは何なのか
- データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？
- データ匿名化 第3回：個人情報を匿名化するプロセス
- データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは
- データ匿名化 第5回：データ匿名化の指標
- データ匿名化 第6回：実際の匿名化 ←今読んでいる記事
匿名加工処理の流れ
実際のデータ匿名化の流れは以下のようになります。
状況によっては多少順序が前後する工程もありそうですが、だいたいはこの流れで問題ないと思います。
それでは1つずつ見ていきたいと思います。
1. 利用用途の定義
まずは匿名加工したデータをどのような目的で利用するかを定義します。 データの匿名化作業に慣れている場合には問題ないのかもしれませんが、以降の工程でどの項目が準識別子なのか、どの項目が機密属性なのか、どの項目をどの程度一般化して問題ないのか、という判断をする際に目的を明確にしておかないと「この項目を一般化するのが一般的」という感覚に引きずられて遠回りをしがちです。
例えば今回のような検索性能の検証データとしてデータセットを匿名化していく場合にも、主な検索項目が自然言語によるフリーテキストなのか、数値項目なのか、日付項目なのか、によってもどの項目をどの程度一般化するのか、という判断が変わってきます。
2. 対象データセットの選定
対象のデータセットは社内で開発しているサービスのデータセットであれば比較的容易に定まるのではないでしょうか。 この際できるだけ実際に運用しているリアルなデータセットを採用する方が良いでしょう。データ定義を元に作成したサンプルデータだとどうしてもデータ作成者によるバイアスがかかってしまい理想のデータセットになってしまいがちです。
社内でドッグフーディングしている環境があれば理想的だと思いますが、目的が「特定の顧客で発生している性能問題の原因特定」みたいな場合は顧客担当者に交渉してデータを利用させてもらうなどの手順を踏まなければならないでしょう。
3. 対象データセットにおける識別子、準識別子、機密属性の定義
対象となるデータセットが決まったら識別子、準識別子、機密属性の定義です。
識別子は用途に左右されずに比較的機械的に定義できると思います。準識別子データセットに依存する部分はありますが、頻繁に扱われるであろう住所、年齢、性別などは準識別子となるでしょう。 機密属性（漏洩すると問題になる項目）はデータセットによりけりなので都度判断が必要になってくると思います。
4. データセットの加工
識別子、準識別子、機密属性が決まったらデータを加工していけます。
識別子の削除
識別子は無条件で削除されます。
準識別子の加工
準識別子については秘匿すると情報量が大きく減ってしまうため、できるだけ秘匿しないよう一般化していきます。 匿名化後のデータセットの用途を考慮して、準識別子の項目を一般化していきます。 以下の記事のように準識別子をそのままにしてしまうと高い確率で特定されてしまうので何らかの加工を加えると良いと思います。
具体的な加工方法については第4回の記事で解説しています。
5. ツールによる評価
実際のデータセットに含まれるレコード数は少なくとも数万件以上あると思いますので手動で評価を行うことは非現実的だと思いますので、ARXといった匿名加工ツールを利用します。
前回説明させていただいたk-匿名性、l-多様性というプライバシーモデルについてもこちらのツールで設定することができます。
ARXの概要
ARXはデータ匿名化に関する包括的なオープンソースソフトウェアです。
を行うことができます。今回は変換には利用せず、データセットの評価にのみ利用しました。
Java製のアプリケーションなのでWindows/macOS/Linux問わず利用することができます。
ARXの基本的な設定方法
インストールを終えて起動したらデータを読み込みます。CSVデータを入力するケースを例にします。
CSVファイルを読み込む
もしくはメニューから [File] > [Import data...] を選択。
※このとき読み込み済みのデータと設定はリセットされるため注意。
各カラムの識別子区分を設定する
各カラムに識別子区分を設定していく。 識別子区分は以下の通り。
- 非機密属性: Insensitive
- 機密属性: Sensitive
- 準識別子: Quasi-idepntifying
- 識別子: Identifying
評価指標を設定する
k-多様性を追加する場合はk-Anonymityを選択してkの値を設定してOKをクリック。
評価結果を確認する
攻撃モデル
3種類の攻撃モデルに対する特定確率という形式で評価されます。
- Prosecutor attacker model / 検察官攻撃者モデル（検察官リスク）
- Journalist attacker model / ジャーナリスト攻撃者モデル（ジャーナリストリスク）
- 特定の人を特定することを目的とした攻撃
- 匿名化されたデータセット内に存在することがわかっている個人に対して、公開されている別の情報ソースを利用して特定を試みる
- Marketer attacker model / マーケッター攻撃者モデル（マーケッターリスク）
- 不特定多数を特定することを目的とした攻撃
- 特定結果の一部が誤っていることを問題としない
- 検察官リスク、ジャーナリストリスクは必ずマーケッターリスクと同等もしくはそれ以上になる
評価値
- Records at risk
- 閾値を超えるリスクを伴うレコードの割合
- Highest risk
- 単一レコードでもっとも高いリスク（特定可能性）
- k=2 であれば多分50%になる
- Success rate
- 平均再特定リスク
- Risk thresholds
これらの指標値を元にプロジェクトごとに設定した閾値をパスするようデータを加工します。当然1度の加工でパスしない場合は一般化の度合いを調整するなどして試行錯誤が必要になります。
参考：今回の取り組みでの目標閾値
今回の取り組みでは以下4点を満たす場合に匿名化されていると設定してデータ加工を行ないました。ご参考になれば。
- Risk thresholds / Main - Highest risk
50%以下 - Records at risk（％）
0% - Highest risk（％）
1%以下 - Success rate（％）
1%以下
まとめ
今回は実際のデータをどのように匿名化していくのかについてお話ししました。 本連載はこれで終わりとなります。
今回の取り組みではElasticsearchとデータ匿名化手法をテーマにし、主にデータ匿名化についての調査、検証を進めていました。 今まではデータの匿名化というものについてなんとなくではわかっているものの、どういうアプローチが確立されていて、どういう評価をすれば良いのかはわかっていませんでしたが、本連載でまとめた内容を理解することでだいぶ理解が進められたと思います。
少し前にTechCrunchで以下のような記事が公開され話題になっていましたが、今であれば「一般化もしない準識別子を残していれば特定できるのは当たり前」だと冷静に読み解くことができるようになりました。
今後、業務で機密属性を含むデータを取扱うことになった場合にもさらに安全に安心してデータを取扱っていけると思います。
かみせんプロジェクトでは今後もテーマを設定して検証を進めていきます。 次のテーマが決まり、検証が進んだらまたレポートを公開していきたいと思いますのでよろしくお願いします。
連載目次
- 『全文検索 〜 Elasticsearchとデータ匿名化手法』
- 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要
- 大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？(Elasticsearch vs pg_bigm)』
- データ匿名化 第1回：匿名化された個人情報とは何なのか
- データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？
- データ匿名化 第3回：個人情報を匿名化するプロセス
- データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは
- データ匿名化 第5回：データ匿名化の指標
- データ匿名化 第6回：実際の匿名化 ←今読んでいる記事
