目的
- 個人情報の保護について調査する機会があり、GCPにおいてそれを実現するサービスであるDLPについて少し実機確認することにした。
- GCP初心者として、この設定はどういう意味なのかな？と思いながらハンズオンを実施する。
GCP Cloud Data Loss Prevention (DLP) とは（自分の理解）
- GCP内で処理されるデータを監査し、機密データ(電話番号、メールアドレス等の個人情報等）の有無の検知やマスキング処理等が可能なサービス。
やったこと
- 一番簡単そうな公式ハンズオン「Cloud Storage にアップロードされたデータの分類の自動化」をそのまま実施する。実施する中で気づいた点等をまとめておく。
- ハンズオンの内容は以下の通り。
- CloudStorageに3つのバケット（①検疫用、②機密情報有り用、③機密情報無し用）を作成する。
- 「①検疫用バケット」にファイルがアップロードされた際に起動する Cloud Functions #1 を作成する。
- Cloud Functions #1 は適切なパラメータを与えてDLP Jobを起動させる。DLP Jobは 対象ファイルの機密情報の有無を監査し、完了後結果をCloud Pub/SubへPublishする。
- Cloud Pub/Sub から結果通知を受けて起動するCloud Functions #2 を作成する。Cloud Functions #2 はファイルに機密情報があれば②機密情報有り用、なければ③機密情報無し用のバケットに移動する。
- いくつかのファイルを①検疫用にバケットにアップロードして、動作を確認する。
構成図
手順
- 基本的にはハンズオンの手順通りに進める。
始める前に
- プロジェクトを作成し、API(Cloud Functions, Cloud Storage, Cloud Data Loss Prevention API) を有効化する。
[サービスアカウントへの権限の付与] (https://cloud.google.com/solutions/automating-classification-of-data-uploaded-to-cloud-storage?hl=ja#granting_permissions_to_service_accounts)
- 指定通りに各サービスアカウントに権限を付与する。
隔離と分類のパイプラインを作成する
Cloud Storage バケットを作成する
- 3つのバケットを作成する。（①検疫用、②機密情報有り用、③機密情報無し用）
Pub/Sub トピックとサブスクリプションを作成する
- Pub/Subのトピックとサブスクリプションを作成する。
Cloud Functions を作成する
-
2つの関数を作成する。
- #1: create_DLP_job: ①検疫用バケットにファイルがアップロードされたことをトリガに起動し、対象ファイル及び検査設定を指定してDLP Jobを起動し、DLPに処理完了をCloud pub/subに出力させる関数。
- #2: resolve_DLP: Cloud pub/subから通知を受けてDLP Jobの処理結果を取得し、結果に応じてファイルを②機密情報有り用バケット、もしくは③機密情報無し用バケットのどちらかに移動させる関数。
-
ハンズオン手順ではConsoleでの作業とgcloudコマンドでの作業の2通りがあるが、今回はgcloudコマンド(Cloud Shell)で実施。gcloudコマンドで手順通り関数を作成しようとしたところ以下のエラーが発生した。
$ gcloud functions deploy create_DLP_job --runtime python37 --trigger-resource "①検疫用バケット" --trigger-event google.storage.object.finalize
ERROR: (gcloud.functions.deploy) Failed to upload the function source code to signed url: ～中略～ <Error><Code>AccessDenied</Code><Message>Access denied.</Message><Details>service-xxxxxxxxxxxx@gcf-admin-robot.iam.gserviceaccount.com does not have storage.objects.create access to the Google Cloud Storage object.</Details></Error>"]
- サービスアカウント「service-xxxxxxxxxxxx@gcf-admin-robot.iam.gserviceaccount.com」 に権限が不足しているようなので、検証環境ということもありとりあえずこのサービスアカウントにOwnerを付与して解決した。
- 今回は機密データとしては以下が指定されている。（ハンズオン資材のmain.pyの設定のまま）電話番号やメールアドレスが検出されることを期待する。（日本語のFirst Nameの検出は厳しいかなと思い）
INFO_TYPES = [
'FIRST_NAME', 'PHONE_NUMBER', 'EMAIL_ADDRESS', 'US_SOCIAL_SECURITY_NUMBER'
]
隔離バケットにサンプル ファイルをアップロードする
ファイルの用意
- ハンズオン資材にも検査対象ファイルが準備されていたが、分かりやすいように自分で用意した。
機密ファイルサンプル.txt
氏名,住所,電話番号
山田太郎,〒200-1111 東京都千代田区1-1-1,090-0000-0000,yamada1@abcdef123.com
山田次郎,〒200-1111 東京都千代田区1-1-2,090-0000-1111,yamada2@abcdef123.com
機密ではないファイルサンプル.txt
氏名,好きな食べ物
山田太郎,みかん
山田次郎,りんご
機密ではないファイルサンプル2.txt
果物,色
みかん,オレンジ
りんご,赤
バナナ,黄色
動作確認
- まず「機密ファイルサンプル.txt」を①検疫用バケットにアップロードする。
- Loggingにて、Cloud Functionsの実行ログを確認する。以下の様子が確認できる。
- 1つ目の関数「create_DLP_job」、2つ目の関数「resolve_DLP」が続けて実行されていること
- EMAIL_ADDRESS と PHONE_NUMBER が検出されたこと
- ファイルを②機密有り用バケットに移動したこと
- DLP Jobsの結果確認画面でも、EMAIL_ADDRESS と PHONE_NUBMER が2件ずつ検出されたことを確認できる。
- 次に「機密ではないファイルサンプル.txt」を①検疫用バケットにアップロードする。機密が検出されないことを期待したが、なぜか「FIRST_NAME」が検出されてしまい、再度②機密有り用バケットのほうに移動されてしまった。
- 最後に「機密ではないファイルサンプル2.txt」を①検疫用バケットにアップロードしたところ、機密は検出されず、③機密無しバケットのほうに移動された。この2つのファイルを処理した際のCloud Functionsのログは以下の通り。
所感
- 処理の流れが理解できる分かりやすいハンズオンだと感じた。機密データを検出後に置換（全部xxx等の伏字にする等）もできるようだが処理がやや面倒だったので今回チャレンジしきれなかった。