プライバシー保護技術について〜Google DLP APIのサンプルを少しだけ触ってみた〜
@positiveflat です。PLAID Advent Calendarの15日目は、プライバシー保護技術についてです。
Google DLP(Data Loss Prevention) APIなどのセンシティブなデータの流出を防ぐためのサービスも出てきており、近年ホットな話題なので、ざっくりと調べてみました。本当にざっくりと。
なぜプライバシー保護技術について調べたのか
弊社PLAIDが提供するKARTEは、顧客が運営しているサイトにタグを埋め込んで、エンドユーザである来訪者一人一人の行動を可視化することができます。この行動データを送るタグの設定によっては、顧客は来訪者についての細かい行動情報や属性情報をKARTEのサーバに送ることも可能です。 また、サイト上でアンケートをとってその結果をKARTEのサーバに送ることなども可能です。蓄積されたエンドユーザの行動データを分析し、その分析結果を元に顧客に価値を提供し、さらにはエンドユーザに より良い体験を届けたいと考えています。しかし、当然ですが個人情報の取り扱いには細心の注意を払わなければなりません。個人情報を保護して、かつ大量のデータの中から有用な知見を得るにはどうしたら良いのか、そのようなビジネス的かつ技術的な要求があり、プライバシー保護技術について調べることにしました。
プライバシー保護技術が扱う問題
データの流出というと、物理的にデバイスを紛失したり、不正アクセスによって攻撃を受けてデータが流出した、というようなことを聞くと思います。しかし、そのようなデータの管理の問題はセキュリティの問題であり、プライバシー保護技術が扱う範囲ではありません。プライバシー保護技術が扱う問題は、 個人情報を保護した上で、
- パーソナルデータをサービスに利用したい
- 統計解析を行いたい
- 機械学習やデータマイニングの教師データとして扱いたい
といったものなようです。
センシティブデータの種類
ひとくくりにデータと言っても、1つのデータで個人を特定できるデータもあれば、複数の情報を組み合わせないと個人を特定できない情報もあったりと、その種類は多岐に渡ります。
- 識別情報：個人を識別可能な情報。あるデータによって直接識別できる場合は直接識別情報、複数のデータの組み合わせで識別できる場合は間接識別情報。
- 履歴情報：個人の活動に関するデータ
- 要配慮情報： 人種・国籍・病歴・宗教など
- 連絡情報：個人に連絡が可能な情報。電話番号など。
- 個人に被害を与える情報：クレジットカード・銀行口座の暗証番号など
プライバシー保護技術のキーワード
あるデータセットがあった時に、そのデータがどの程度プライバシーを守ることができているかを測るための、様々なメトリクスが提案されています。
- k匿名性：あるデータの中に、同じ属性を持つ人がk人いたとして、kが十分大きければ、匿名性は高いと言える。しかし、kが1人しかいなければ、その属性を持った人が見つかればその人のプライバシーが脅かされる恐れがある。同じ属性を持つ人がk以上いる状態を、k匿名性が保たれている状態と言える。
- l多様性：k匿名性を保てていたとしても、k人の中で別の隠したい属性（例えば居住地等）に多様性がなかった場合、そのk人の属性が特定されてしまう。l多様性は、その属性がl個の多様性を持っていることを示す。
また、これらのメトリックスを制約にして、プライバシーを保護するようにデータを加工する技術もあります。
- k匿名化：k匿名性を保つように、データを加工すること。例えば元のデータには具体的な年齢が書かれていたとしても、21~25才とすることで属性の数が減り、匿名性が高まる。
- 差分プライバシー：統計情報などを渡す際に、ノイズを加えることで元のデータを推定できにくくする技術。
- 秘密計算：複数の人や組織同士でお互いに詳細なデータの中身は秘密にした状態で、統計データなどの計算を行う技術。
かなり大雑把に独自の解釈を書きましたので、厳密な定義については書籍などをご参照ください。
Google DLP APIのサンプルを触ってみた
Googleが2017年3月にベータ版をリリースしたGoogle DLP APIは、APIにテキストか画像のデータを渡すか、
- Google Cloud Storage
- BigQuery
- Cloud Datastore
などに蓄積されているデータを指定することで、
- クレジットカード
- Social security number
- パスポート番号
- 運転免許証番号
- 電話番号
などを50以上のclassifierによってセンシティブ情報を特定してくれるそうです（日本だと、マイナンバーやパスポートナンバー用のものが用意されているようです）。また、データを保存する前にセンシティブ情報が含まれていることを認識して、どこに保存すべきかを区別することも可能だそうです。
node.jsのクライアントが用意されていたので、今回はこちらを少しだけ触ってみました。
以下のようなサンプルデータをこのサイトで作成して試してみました。
first_name,last_name,phone number,creditcard number
Issy,Tugwell,453-138-1080,3544989420121353
Melodie,Dooher,936-496-0728,6759986094537891
Archibaldo,Storrs,988-688-8450,3567156525401872
Mill,Agge,611-721-6243,201514923658428
Sadye,Guillet,421-144-4218,5564765386495738
Kenyon,Hansman,455-711-7116,5602254739460878964
Abel,Renahan,874-626-0899,3528877993188372
...同じリポジトリにsampleのコードが入っていたので実行してみました。
➜ samples git:(master) node ./inspect.js file ./MOCK_DATA.csvFindings:Quote: 3544989420121353Info type: CREDIT_CARD_NUMBERLikelihood: POSSIBLEQuote: 936-496-0728Info type: PHONE_NUMBERLikelihood: POSSIBLEQuote: 6759986094537891Info type: CREDIT_CARD_NUMBERLikelihood: POSSIBLE...
デフォルトでは電話番号、メールアドレス、クレジットカードを検査するように指定されているので、今回は電話番号とクレジットカードが引っかかりました。ちなみに何も考えずにそのまま叩いただけですと、いくつか電話番号として認識されないものもありました。尤度の設定等色々指定できるので、調整する必要がありそうです。
API Documentにもありますが、それらのデータを別の文字に変換することも可能です。また、v2では上で触れたk匿名性やl多様性など、リスクを評価するメトリクスも計算できるようです。
感想
ざっくりと調べてみていて感じたことは、プライバシー保護技術はセンシティブなデータを確実に秘匿することを保証する技術ではなさそうだ、ということです。もちろんかなり大胆にデータを加工してしまえば確実な秘匿は可能かもしれません。しかし、このようにしてしまうと機械学習やデータマイニングなどで使用する際に、データが持つ有用性が損なわれることは言うまでもありません。非常に便利そうな技術ではあるものの、ビジネスに持ち込むにはかなりしっかりと考えて使わなければならないと感じました。
