1. 概要
現代の組織では、さまざまなソースからデータが取り込まれる量が増加の一途をたどっています。そのためには、データを戦略的に保存、保護するためにデータの隔離と分類が必要になることがよくありますが、この作業はすぐに費用がかかり、手作業のままでは実現不可能になります。
この Codelab では、Cloud Storage にアップロードされたデータを自動的に分類し、対応するストレージ バケットに移動する方法を説明します。そのためには、Cloud Pub/Sub、Cloud Functions、Cloud Data Loss Prevention、Cloud Storage を使用します。
演習内容
- 検疫と分類のパイプラインの一部として使用する Cloud Storage バケットを作成する。
- ファイルのアップロード時に DLP API を呼び出す簡単な Cloud Functions の関数を作成する。
- ファイル処理の完了を通知する Pub/Sub トピックとサブスクリプションを作成する。
- サンプル ファイルを検疫バケットにアップロードして Cloud Functions の関数を呼び出す
- DLP API を使用してファイルを検査、分類し、適切なバケットに移動する。
必要なもの
- お支払い情報が設定された Google Cloud プロジェクト。アカウントがない場合は、アカウントを作成する必要があります。
2. 設定方法
この Codelab では、Cloud Shell からコマンドラインを使用して、さまざまなクラウド リソースとサービスのプロビジョニングと管理を行います。次のコマンドで、Cloud Shell エディタとともに Cloud Shell を開き、コンパニオン プロジェクト リポジトリのクローンを作成します。
gcloud config set project [PROJECT_ID] で設定し、正しいプロジェクトを使用していることを確認してください。
API を有効にする
Google Cloud プロジェクトで必要な API を有効にします。
- Cloud Functions API - イベントに応答して実行されるユーザー提供の軽量関数を管理します。
- Cloud Data Loss Prevention（DLP）API - テキスト、画像、Google Cloud Platform ストレージ リポジトリに含まれる、プライバシーに配慮したフラグメントの検出、リスク分析、匿名化を行います。
- Cloud Storage - Google Cloud Storage は、お客様のデータを Google のインフラストラクチャに格納してアクセスするための RESTful サービスです。
サービス アカウントの権限
サービス アカウントは特別なタイプのアカウントで、アプリケーションと仮想マシンが、承認された API 呼び出しを行うときに使用されます。
App Engine のデフォルトのサービス アカウント
App Engine のデフォルトのサービス アカウントは、App Engine で実行されているアプリに代わって、Cloud プロジェクトでタスクを実行するために使用します。このサービス アカウントは、デフォルトでプロジェクトに存在し、編集者のロールが割り当てられています。
まず、データ損失防止（DLP）ジョブの管理に必要な DLP 管理者ロールをサービス アカウントに付与します。
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \ --member serviceAccount:$GOOGLE_CLOUD_PROJECT@appspot.gserviceaccount.com \ --role roles/dlp.admin
最後に、BigQuery、ストレージ、データストア、Pub/Sub、鍵管理サービスに対するサービス アカウント権限を許可する DLP API サービス エージェントのロールを付与します。
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \ --member serviceAccount:$GOOGLE_CLOUD_PROJECT@appspot.gserviceaccount.com \ --role roles/dlp.serviceAgent
DLP サービス アカウント
ここでは、App Engine サービス アカウントに加えて DLP サービス アカウントも使用します。このサービス アカウントは、DLP API が有効になったときに自動的に作成され、最初はどのロールも付与されていません。これに閲覧者ロールを付与します。
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT \ --member serviceAccount:service-`gcloud projects list --filter="PROJECT_ID:$GOOGLE_CLOUD_PROJECT" --format="value(PROJECT_NUMBER)"`@dlp-api.iam.gserviceaccount.com \ --role roles/viewer
3. Cloud Storage バケット
データを保存する 3 つの Cloud Storage バケットを作成する必要があります。
- 検疫バケット: データは最初にここにアップロードされます。
- 機密データ バケット: DLP API によって機密と判定されたデータがここに移動します。
- 機密性の低いデータバケット: DLP API によって機密ではないと判断されたデータがここに移動します
gsutil コマンドを使用すると、3 つのバケットすべてを 1 ステップで作成できます。
gsutil mb gs://[YOUR_QUARANTINE_BUCKET] \ gs://[YOUR_SENSITIVE_DATA_BUCKET] \ gs://[YOUR_NON_SENSITIVE_DATA_BUCKET]
先ほど作成したバケットの名前をメモしておきます。後で必要になります。
4. Pub/Sub トピックとサブスクリプション
Cloud Pub/Sub は、アプリケーション間で多対多の非同期メッセージングを行います。パブリッシャーはメッセージを作成し、それをトピックと呼ばれるメッセージのフィードにパブリッシュします。サブスクライバーは、subscription を介してこれらのメッセージを受信します。このサブスクリプションに基づいて、この場合は Cloud Functions の関数が DLP ジョブの実行後にファイルをそれぞれのバケットに移動します。
まず、トピックを作成します。ファイルが検疫用ストレージ バケットに追加されるたびに、ここにメッセージが公開されます。「classify-topic」という名前にします。
gcloud pubsub topics create classify-topic
トピックがメッセージをパブリッシュすると、サブスクリプションに通知されます。「classify-sub」という名前の Pub/Sub サブスクリプションを作成しましょう。
gcloud pubsub subscriptions create classify-sub --topic classify-topic
このサブスクリプションによって 2 つ目の Cloud Functions の関数がトリガーされ、DLP ジョブが開始されてファイルの検査と適切な場所への移動が行われます。
5. Cloud Functions
Cloud Functions を使用すると、サーバーやランタイム環境を管理せずに、軽量なイベントベースで非同期の単一目的の関数をデプロイできます。dlp-cloud-functions-tutorials/gcs-dlp-classification-python/ にある main.py ファイルを使用して、2 つの Cloud Functions の関数をデプロイします。
変数の置換
関数を作成する前に、main.py ファイル内のいくつかの変数を置き換える必要があります。
Cloud Shell エディタで main.py を調整し、28 ～ 34 行目のプロジェクト ID とバケット変数の値を、先ほど作成した対応するバケットに置き換えます。
main.py
PROJECT_ID = '[PROJECT_ID_HOSTING_STAGING_BUCKET]'
"""The bucket the to-be-scanned files are uploaded to."""
STAGING_BUCKET = '[YOUR_QUARANTINE_BUCKET]'
"""The bucket to move "sensitive" files to."""
SENSITIVE_BUCKET = '[YOUR_SENSITIVE_DATA_BUCKET]'
"""The bucket to move "non sensitive" files to."""
NONSENSITIVE_BUCKET = '[YOUR_NON_SENSITIVE_DATA_BUCKET]'
さらに、pub/sub トピック変数の値を、前のステップで作成した Pub/Sub トピックに置き換えます。
""" Pub/Sub topic to notify once the DLP job completes."""
PUB_SUB_TOPIC = 'classify-topic'
関数をデプロイする
Cloud Shell で、main.py ファイルが存在する gcs-dlp-classification-python ディレクトリに移動します。
cd ~/cloudshell_open/dlp-cloud-functions-tutorials/gcs-dlp-classification-python
ここで、いくつかの関数をデプロイします。
まず、create_DLP_job 関数をデプロイします。[YOUR_QUARANTINE_BUCKET] は適切なバケット名に置き換えてください。この関数は、指定された Cloud Storage 検疫バケットに新しいファイルがアップロードされるとトリガーされ、アップロードされたファイルごとに DLP ジョブを作成します。
gcloud functions deploy create_DLP_job --runtime python37 \ --trigger-event google.storage.object.finalize \ --trigger-resource [YOUR_QUARANTINE_BUCKET]
次に、トピックをトリガーとして指定する resolve_DLP 関数をデプロイします。この関数は、上記の関数の後続の DLP ジョブで開始された Pub/Sub 通知をリッスンします。Pub/Sub 通知を受信するとすぐに DLP ジョブから結果を取得し、ファイルを機密バケットまたは機密でないバケットに移動します。
gcloud functions deploy resolve_DLP --runtime python37 \ --trigger-topic classify-topic
確認
gcloud functions describe コマンドを使用して、両方の Cloud Functions 関数が正常にデプロイされたことを確認します。
gcloud functions describe create_DLP_job
gcloud functions describe resolve_DLP
正常にデプロイされると、出力にはステータスが ACTIVE と表示されます。
6. サンプルデータでテストする
すべての要素が揃ったので、いくつかのサンプル ファイルを使用してテストを実行できます。Cloud Shell で、現在の作業ディレクトリを sample_data に変更します。
cd ~/cloudshell_open/dlp-cloud-functions-tutorials/sample_data
サンプル ファイルは、さまざまなデータを含む txt ファイルと CSV ファイルで構成されています。接頭辞が「sample_s」のファイル接頭辞「sample_n」が付いているデータには機密データが含まれます。できません。たとえば、sample_s20.csv には、米国の社会保障番号のような形式が含まれています。
sample_s20.csv
Name,SSN,metric 1,metric 2
Maria Johnson,284-73-5110,5,43
Tyler Parker,284-73-5110,8,17
Maria Johnson,284-73-5110,54,63
Maria Johnson,245-25-8698,53,19
Tyler Parker,475-15-8499,6,67
Maria Johnson,719-12-6560,75,83
Maria Johnson,616-69-3226,91,13
Tzvika Roberts,245-25-8698,94,61
一方、sample_n15.csv のデータは機密とはみなされません。
sample_n15.csv
record id,metric 1,metric 2,metric 3
1,59,93,100
2,53,13,17
3,59,67,53
4,52,93,34
5,14,22,88
6,18,88,3
7,32,49,5
8,93,46,14
設定でファイルがどのように処理されるかを確認するために、すべてのテストファイルを検疫にアップロードします。
バケット:
gsutil -m cp * gs://[YOUR_QUARANTINE_BUCKET]
最初は、ファイルがアップロードされた検疫バケットに保管されます。これを確認するには、ファイルをアップロードした直後に、検疫バケットの内容を一覧表示します。
gsutil ls gs://[YOUR_QUARANTINE_BUCKET]
開始した一連のイベントを確認するには、まず Cloud Functions のページに移動します。
create_DLP_job 関数の [操作] メニューをクリックし、[ログを表示] を選択します。
この関数のログには、各ファイルに対して少なくとも 4 つのエントリがあります。
- 関数の実行を開始しました
- 特定のファイルに対して関数がトリガーされました
- ジョブが作成された
- 関数の実行が終了した
各ファイルに対して create_DLP_job 関数が完了すると、対応する DLP ジョブが開始されます。[DLP ジョブ] ページに移動して、キュー内の DLP ジョブの一覧を表示します。
[Pending]、[Running]、[Done] のジョブのリストが表示されます。これらはそれぞれ、アップロードしたファイルのいずれかに対応しています。
これらのジョブの ID をクリックすると、詳細が表示されます。
Cloud Functions ページに戻り、resolve_DLP 関数からログアウトすると、各ファイルに少なくとも 8 つのエントリが表示されます。これは、次のことを示しています。
- 関数の実行を開始しました
- Pub/Sub 通知を受信しました
- 対応する DLP ジョブの名前
- ステータス コード
- 機密データのインスタンスの数（存在する場合）
- ファイルの移動先となるバケット
- DLP ジョブによるファイルの解析が完了しました
- 関数の実行が終了した
resolve_DLP 関数のすべての呼び出しが完了したら、すぐに検疫バケットの内容をもう一度確認します。
gsutil ls gs://[YOUR_QUARANTINE_BUCKET]
今回は完全に空になります。他のバケットに対しても上記と同じコマンドを実行すると、ファイルは対応するバケットに完全に分離されます。
7. クリーンアップ
DLP API を Cloud Functions の関数と組み合わせてデータを分類する方法を確認できたので、今度は作成したすべてのリソースのプロジェクトをクリーンアップしましょう。
プロジェクトを削除する
必要に応じて、プロジェクト全体を削除することもできます。GCP Console で、[Cloud Resource Manager] ページに移動します。
プロジェクト リストで、目的のプロジェクトを選択し、[削除] をクリックします。プロジェクト ID を入力するように求められます。入力して [シャットダウン] をクリックします。
また、gcloud を使用して Cloud Shell からプロジェクト全体を直接削除することもできます。
gcloud projects delete [PROJECT_ID]
異なるコンポーネントを 1 つずつ削除する場合は、次のセクションに進みます。
Cloud Functions
gcloud で両方の Cloud Functions の関数を削除します。
gcloud functions delete -q create_DLP_job && gcloud functions delete -q resolve_DLP
ストレージ バケット
アップロードされたすべてのファイルを削除し、gsutil を使用してバケットを削除します。
gsutil rm -r gs://[YOUR_QUARANTINE_BUCKET] \ gs://[YOUR_SENSITIVE_DATA_BUCKET] \ gs://[YOUR_NON_SENSITIVE_DATA_BUCKET]
Pub/Sub
まず、gcloud を使用して Pub/Sub サブスクリプションを削除します。
gcloud pubsub subscriptions delete classify-sub
最後に、gcloud を使用して Pub/Sub トピックを削除します。
gcloud pubsub topics delete classify-topic
8. 完了
これで完了です。ここでは、DLP API と Cloud Functions を使用してファイルの分類を自動化する方法を学習しました。
学習した内容
- センシティブ データと非センシティブ データを保存するために Cloud Storage バケットを作成しました。
- Cloud Functions の関数をトリガーする Pub/Sub トピックとサブスクリプションを作成しました
- Google は、ファイルに含まれる機密データに基づいてファイルを分類する DLP ジョブを開始するために Cloud Functions を作成しました。
- テストデータをアップロードしStackdriver ログでプロセスの動作を確認する