Google Cloud を活用した PII の検索方法と保護方法

※この投稿は米国時間 2022 年 9 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

BigQuery は今日の市場における代表的なデータ ウェアハウス ソリューションであり、データに関する詳細な情報と高度な分析を必要とするお客様から高く評価されています。一般的な BigQuery のユースケースとして、多くの場合、個人を特定できる情報（PII）の保存と処理が含まれます。これらのデータは、Google Cloud 内で不正なアクセスや悪意あるアクセスから保護する必要があります。

BigQuery データから PII を検索して特定するプロセスは、そのほとんどを手作業による PII の検出と複製に依存しています。一般的な方法としては、PII に使用されている列を抽出して、アクセスが制限された別のテーブルにコピーする方法があります。ただし、このようにデータの余分なコピーを作成して手作業で PII を特定することで、ミスやその後のセキュリティ イベントのリスクを高めてしまいます。

さらに、PII データのセキュリティは多くの場合、複数の規則によって義務付けられており、適切な安全保護対策を適用しないと、重い罰則が科される可能性があります。この問題に対処するために、お客様には、1) BigQuery で PII を識別し、2) そのデータにアクセス制御を自動的に実装して、不正なアクセスや悪用を防止するソリューションが必要です。  

このブログでは、Google プロフェッショナル サービスにより開発された、Google Cloud DLP を活用してセンシティブ データを検査および分類するソリューションについて説明し、これらの分析情報を利用して BigQuery テーブル内のデータに自動的にタグ付けして保護するソリューションを提案します。

BigQuery 自動タグ付けソリューションの概要

Automatic DLP は、BigQuery 内の PII などのセンシティブ データを特定するのに役立ちます。組織は Automatic DLP を活用して、BigQuery データ ウェアハウス全体でセンシティブ データ フィールドを含むテーブルを自動的に検索し、詳細な調査結果をコンソール（下の図 1 を参照）やデータポータルで、構造化された形式（BigQuery 結果テーブルなど）で報告できます。新しく作成されたテーブルや更新されたテーブルは、ユーザーが呼び出しやスケジュール設定をしなくても、バックグラウンドで自動的に検出、スキャン、分類できます。このようにして、センシティブ データを継続的に確認できます。

今回は、BigQuery 自動タグ付けソリューションという新しいオープンソース ソリューションが、データのアクセス制御の自動化という第二の目標をどのように解決するのかを紹介します。このソリューションは、Automatic DLP の上位レイヤとして位置づけられ、列レベルのアクセス制御を自動的に実施して、ユーザー定義のデータ分類法（高機密性や低機密性など）と分野（マーケティング、財務、ERP システムなど）に基づいて、特定のセンシティブ データ タイプへのアクセスを制御します。このソリューションは、PII へのアクセスが無制限な状態のリスクを最小限に抑え、列レベルまで適切なアクセス制御を適用したうえで、データのコピーが 1 つだけであることを保証するものです。

このソリューションのコードは、GitHub の GoogleCloudPlatform/bq-pii-classifier で公開されています。Google はこのコードを管理していませんが、このコードを実装する方法については、営業担当者経由で Google プロフェッショナル サービスチームまでお問い合わせください。  

BigQuery と Data Catalog ポリシータグ（現在の Dataplex）にはいくつかの制限があり、このソリューションを実装する前に、お客様の組織で確実に機能するかを確認する必要があります。

• 分類とポリシータグはリージョン間で共有されない: 複数のリージョンにデータがある場合は、ポリシータグを適用するリージョンごとに分類を作成または複製する必要があります。

• プロジェクトあたりの分類数は最大 40 個: ビジネス分野ごとに異なる分類が必要な場合、または複数のクラウド リージョンをサポートするためのレプリケーションがある場合、これらの分類はこの割り当てにカウントされます。

• 分類あたりのポリシータグは最大 100 個: Cloud DLP は、分類の infoType を最大 150 個サポートしますが、1 つのポリシー分類では、ネストされたカテゴリを含めて最大 100 個までしかサポートできません。100 以上のデータ型をサポートする必要がある場合、複数の分類に分割する必要があります。

ソリューションの概要

このソリューションは、主に Dispatcher Requests トピック、Dispatcher サービス、BigQuery Policy Tagger Requests トピック、BigQuery Policy Tagger サービス、ロギング コンポーネントで構成されています。

Dispatcher Service は、BigQuery スコープがプロジェクト、データセット、テーブルの包含リストと除外リストとして表現されることを想定した Cloud Run サービスです。この Dispatcher サービスは、Automatic DLP データ プロファイルにクエリを実行して、スコープ内のテーブルにデータ プロファイルが生成されているかどうかを確認します。これらのテーブルでは、テーブルごとに 1 つのリクエストを「BigQuery Policy Tagger Requests」Pub/Sub トピックにパブリッシュします。このトピックは、BigQuery 列のタグ付けオペレーションのレート制限を有効にし、バックオフによる自動再試行を適用します。

また、「BigQuery Policy Tagger」サービスも、BigQuery テーブルの DLP スキャン結果の情報を受け取る Cloud Run サービスです。このサービスは、各列の最終的な InfoType を決定し、InfoType - ポリシータグのマッピングで定義されている適切なポリシータグを適用します。INFO_TYPE が 1 つのみ選択され、関数により関連するポリシータグが割り当てられます。

最終的に、すべての Cloud Run サービスは、ログシンクによって BigQuery にエクスポートされる構造化ログを保持します。Cloud Run の呼び出しチェーンのモニタリングやデバッグ、列へのタグ付けアクションに役立つ BigQuery ビューが複数用意されています。

デプロイについて

このソリューションは、デプロイ後に 2 つの異なる方法で使用できます。

[オプション 1] Automatic DLP トリガーによる即時タグ付け:

Automatic DLP は、検査ジョブが完了するたびに Pub/Sub 通知を送信するように構成されています。Pub/Sub 通知にはリソース名が含まれており、それが Tagger サービスを直接トリガーします。

[オプション 2] スケジュール設定されたタグ付け:

このシナリオでは、BigQuery スコープを表すペイロードを使用してスケジュールに基づいて Dispatcher サービスが呼び出され、Automatic DLP によって検査されたテーブルが一覧表示されて、テーブルごとにタグ付けリクエストが作成されます。Cloud Scheduler（または任意のオーケストレーション ツール）を使用して Dispatcher サービスを呼び出せます。ソリューションが VPC-SC 境界内にデプロイされている場合は、VPC-SC をサポートする他のスケジューラー（Composer やカスタムアプリなど）を使用する必要があります。

さらに、複数の Cloud Scheduler / Trigger を定義して、同じタグ付けスケジュール（毎日または毎月など）を持つプロジェクト / データセット / テーブルをグループ化できます。

Automatic DLP の詳細については、Google のウェブページをご覧ください。BQ 分類器の詳細については、GitHub のオープンソース プロジェクト: GoogleCloudPlatform/bq-pii-classifier をご覧いただき、ぜひ今すぐお試しください。