Contents
スポンサードリンク
1. 全体像と主要コンポーネントの役割
| コンポーネント | 主な機能 | 連携ポイント |
|---|---|---|
| Dataplex Universal Catalog | データ資産（テーブル・ビュー・ファイル）の自動検出、ビジネスメタデータ登録、血統（Lineage）可視化 | IAM と組み合わせて「誰が何を検索できるか」を制御。ポリシータグや DLP の対象テーブルを一元管理。 |
| IAM | プロジェクト・データセット・テーブル単位でのロール付与、条件付きロール（IAM 条件式） | ポリシータグが付いた列に対して カスタムロール + 条件 を適用し、列レベルアクセスを実現。 |
| ポリシータグ | 列やビューに「機密情報」タグを付与し、IAM と連動させてアクセス制御 | DLP が検出した PII に自動でタグ付け → 条件付きロールが適用されるフロー。 |
| Data Loss Prevention (DLP) | 機微情報（PII・PCI など）の自動検出、マスキング／置換テンプレートの適用 | スキャン結果をポリシータグに反映させ、継続的な保護と監査証跡を提供。 |
ポイント
- 検索性・可視化：Dataplex が全データ資産のインベントリを作成。
- 最小権限：IAM と条件付きロールで「必要な人だけが必要な列にアクセス」できるようにする。
- 自動保護：DLP → ポリシータグ → 条件付き IAM のサイクルで、タグ付け漏れを防止。
2. Dataplex Universal Catalog の有効化とメタデータ登録
2‑1. 前提条件・リージョン注意点
- Dataplex は
us-central1,europe-west1などの 単一ロケーション に作成します。対象の BigQuery データセットは同じロケーションである必要があります（マルチリージョンの場合はUS・EUを選択）。 - DLP のスキャンも実行場所を指定しないと global になるため、データが保存されているロケーションと合わせることが推奨されます。
2‑2. 有効化手順（CLI + コンソール）
|
1 2 3 4 5 6 7 8 |
# 1️⃣ Dataplex API を有効化 gcloud services enable dataplex.googleapis.com # 2️⃣ カタログ作成 (us-central1 に例示) gcloud dataplex catalogs create my-catalog \ --location=us-central1 \ --display-name="組織データカタログ" |
コンソール → Dataplex → 「カタログを作成」→ 名前・ロケーションを入力でも可。
2‑3. BigQuery テーブル／ビューの自動登録
Dataplex は BigQuery のメタデータ を自動でインベントリ化しますが、タグ付け（ビジネスオーナーなど）は手動または Cloud Functions 経由で行います。
手動ラベル付与例（テーブルに Dataplex カタログ ID を紐付け）
|
1 2 3 4 |
bq update \ --set_label=dataplex_catalog=my-catalog \ my-project:my_dataset.my_table |
--add_label→--set_labelに変更。ラベルは キー＝値 の形式で BigQuery テーブルに保存され、Dataplex が自動的に認識します。
2‑4. 手動タグ付け（ビジネスオーナー等）
| 方法 | 手順 |
|---|---|
| コンソール | Dataplex → カタログ → 該当エンティティ → 「タグを追加」→ キー owner、値 marketing など |
| CLI（Data Catalog API） | gcloud data-catalog tags create …（詳細は公式ドキュメント参照） |
ポイント：Dataplex のメタデータは検索・血統解析に直結するため、ビジネスオーナー情報は必ず付与しておくと監査が楽になります。
3. IAM ロール設計のベストプラクティス
3‑1. 権限階層と最小権限の実装例
| 階層 | 推奨ロール | 主な権限（抜粋） |
|---|---|---|
| プロジェクト | roles/bigquery.jobUser |
クエリ実行・ジョブ作成 |
| データセット | roles/bigquery.dataViewer (閲覧) roles/bigquery.dataEditor (書き込み) |
テーブル一覧取得、テーブル読み取り/書き込み |
| テーブル / 列 | カスタムロール bigquery.columnReader（ポリシータグ条件付き） |
bigquery.tables.get, bigquery.jobs.create, bigquery.tables.updateData |
カスタムロール作成例
|
1 2 3 4 5 6 7 |
gcloud iam roles create bigquery.columnReader \ --project=my-project \ --title="BigQuery Column Reader" \ --description="Read columns protected by policy tags only when condition is met." \ --permissions=bigquery.tables.get,bigquery.jobs.create \ --stage=GA |
3‑2. 条件付き IAM の具体的構文
目的：PII_Sensitive ポリシータグが付与された列に対し、特定ロールを 条件付きで 付与する。
|
1 2 3 4 5 6 7 8 |
gcloud projects add-iam-policy-binding my-project \ --member=user:alice@example.com \ --role=roles/bigquery.columnReader \ --condition=None \ --expression="resource.name.startsWith('projects/my-project/datasets/my_dataset/tables/') && \ resource.labels.policyTag == 'PII_Sensitive'" \ --title="Read PII columns only" |
resource.nameはテーブルのフルパス（例:projects/<project>/datasets/<dataset>/tables/<table>）resource.labels.policyTagは ポリシータグ ID（PII_Sensitiveではなく実際のタグ ID）を指す。- 条件式は Common Expression Language (CEL) に準拠し、Cloud Console の「IAM → 条件付きロール」でも同様に設定可能。
注意点
- ポリシータグは リージョン固有（
projects/<project>/locations/<region>/policyTags/<tag-id>）であるため、条件式でも同一のregionを使用する必要があります。 - 条件付きロールは データセットレベルではなくテーブル/列レベル に適用できるので、機密度に応じた粒度を選択してください。
4. 列レベルセキュリティ – ポリシータグの作成・適用フロー
4‑1. ポリシータグテンプレート（Data Catalog）作成
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# Data Catalog にポリシータグテンプレートを作成 (us-central1) gcloud data-catalog taxonomies create \ --location=us-central1 \ --display-name="PII_Taxonomy" \ --description="個人情報に関するタグ階層" # 作成したタクソノミーにポリシータグを追加 gcloud data-catalog policy-tags create \ --taxonomy=my-taxonomy-id \ --display-name="PII_Sensitive" \ --description="個人情報保護対象列" |
my-taxonomy-idは上記タクソノミー作成時に返されるリソース名（例:projects/123/locations/us-central1/taxonomies/456）。
4‑2. テーブル・列へのポリシータグ付与
正しい CLI 構文（2024 年版）
|
1 2 3 4 |
bq update \ --set_policy_tag=projects/my-project/locations/us-central1/policyTags/1234567890abcdef \ my-project:my_dataset.my_table.column_name |
--set_policy_tagの引数は フルリソース名（プロジェクト・ロケーション・ポリシータグ ID）であることに注意。- 複数列に同時付与したい場合はカンマ区切りで
column1,column2,...と指定可能。
4‑3. 条件付き IAM の適用例（再掲）
|
1 2 3 4 5 6 7 8 |
gcloud projects add-iam-policy-binding my-project \ --member=user:bob@example.com \ --role=roles/bigquery.columnReader \ --condition=None \ --expression="resource.name.startsWith('projects/my-project/datasets/finance/tables/') && \ resource.labels.policyTag == '1234567890abcdef'" \ --title="Finance PII Reader" |
ポイント：ロールは
bigquery.columnReaderのように最小権限だけを持つカスタムロールとし、条件式で対象ポリシータグのみ許可することで「列レベルの最小権限」実装が完了します。
5. Data Loss Prevention（DLP）との連携
5‑1. DLP スキャンジョブ作成（リージョン指定付き）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
gcloud beta dlp jobs create \ --display-name="PII Scan - finance_dataset" \ --inspect-config='{ "infoTypes":[{"name":"PERSON_NAME"},{"name":"CREDIT_CARD_NUMBER"}], "minLikelihood":"LIKELY" }' \ --storage-config='{ "bigQueryOptions":{ "tableReference":{"projectId":"my-project","datasetId":"finance","tableId":"transactions"} } }' \ --location=us-central1 |
--locationで DLP の実行リージョンを明示。BigQuery データセットと同一ロケーションにするとレイテンシが低減し、リージョン制約エラーを回避できます。
5‑2. マスキング（置換）テンプレート例
masking_template.json
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
{ "infoTypeTransformations": [ { "infoTypes": [{"name":"CREDIT_CARD_NUMBER"}], "primitiveTransformation": { "replaceWithInfoTypeConfig": {} } }, { "infoTypes": [{"name":"PERSON_NAME"}], "primitiveTransformation": { "redactConfig": {} } } ] } |
テンプレートの適用はジョブ作成時に --deidentify-config オプションで指定します（必要に応じて Cloud DLP API の REST 呼び出しでも可）。
5‑3. スキャン結果をポリシータグへ自動反映
- スキャン結果 CSV を Cloud Storage にエクスポート
bash
gcloud beta dlp jobs describe <JOB_ID> --location=us-central1 \
--format="value(outputInfo.outputConfig.tableReference)" - Dataflow（Python） で CSV → BigQuery テーブルにロードし、列ごとに ポリシータグ ID を取得。
- BigQuery API (
tables.update) を呼び出して--set_policy_tagを自動付与。
このフローは「検出→タグ付与」の完全自動化を実現し、手作業による漏れリスクを大幅に低減します。
6. 監査ログ（Cloud Audit Logs）とモニタリング
6‑1. Audit Logs の有効化
| ログ種別 | 推奨設定 |
|---|---|
Data Read (bigquery.googleapis.com/dataRead) |
ON（全ユーザー・サービスアカウント） |
Data Write (bigquery.googleapis.com/dataWrite) |
ON |
| Admin Activity | デフォルトで ON（変更操作は必ず記録） |
コンソール → IAM と管理 → 監査ログ → 該当 API を選択し、対象の「サービスアカウント」や「ユーザー」をすべてオンにします。
6‑2. ログエクスポート先と分析ビュー
|
1 2 3 4 5 |
# Cloud Logging の Sink 作成（BigQuery にエクスポート） gcloud logging sinks create bq-audit-logs \ bigquery.googleapis.com/projects/my-log-project/datasets/audit_logs \ --log-filter='resource.type="bigquery_resource" AND (protoPayload.methodName:"jobservice.insertJob" OR protoPayload.methodName:"tableservice.getTable")' |
代表的な分析クエリ（過去7日間の読取件数）
|
1 2 3 4 5 6 7 8 9 10 |
SELECT protopayload_auditlog.authenticationInfo.principalEmail AS user, TIMESTAMP_TRUNC(timestamp, DAY) AS day, COUNT(*) AS read_operations, SUM(jsonPayload.serviceData.jobCompletedEvent.job.jobStatistics.queryStats.totalBytesProcessed) / (1024*1024*1024) AS gb_processed FROM `my-log-project.audit_logs.cloudaudit_googleapis_com_bigquery_data_read` WHERE timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) GROUP BY user, day ORDER BY day DESC, read_operations DESC; |
6‑3. アラート設定例（Cloud Monitoring）
| メトリクス | 閾値例 | 通知先 |
|---|---|---|
bigquery.googleapis.com/query/count |
> 5000 / hour （急激な増加） | Slack/Webhook |
bigquery.googleapis.com/bytes_processed |
> 2 TB / day（大量データ抽出） | Email + PagerDuty |
7. 運用チェックリスト & コンプライアンス評価ポイント
| カテゴリ | 確認項目 | 推奨方法 |
|---|---|---|
| Catalog 登録 | 全テーブル・ビューが Dataplex に表示されているか | gcloud dataplex entities list --catalog=my-catalog で確認 |
| IAM 設定 | プロジェクト・データセットのロールが最小権限に絞られているか | IAM ポリシーをエクスポートし、不要な roles/editor が無いことを検証 |
| ポリシータグ | 機密列に正しいタグ ID が付与され、条件付きロールが機能しているか | bq show --format=prettyjson my_dataset.my_table で policyTags を確認 |
| DLP スキャン | 定義した InfoType が期待通り検出・マスクされたか | DLP ジョブ結果の CSV と BigQuery の実データを突合 |
| 監査ログ | Data Read/Write ログが Cloud Logging にエクスポートされ、保持期間がポリシーに沿っているか | Logging > Logs Explorer で logName:"cloudaudit.googleapis.com" を検索 |
| アラート | 異常アクセス時の通知が正しく届くか（テスト実行） | Cloud Monitoring の「テスト」ボタンでシミュレーション |
コンプライアンス評価ポイント
1. データインベントリ：Catalog が最新かつメタデータが完全か。
2. アクセス制御：最小権限＋条件付き IAM がポリシー要件に合致しているか。
3. 機密情報保護：DLP とポリシータグの連携で網羅的に PII がタグ付けされているか。
4. 監査証跡：全操作がログとして残り、保持期間・エクスポート設定が適切か。
8️⃣ まとめ（要点）
- Dataplex → データ資産のカタログ化と血統可視化
- IAM + 条件付きロール → プロジェクト/データセット/列レベルで最小権限を実現
- ポリシータグ → 列単位の機密情報にタグ付けし、IAM と連携させてアクセス制御
- DLP → 検出・マスキングを自動化し、結果をポリシータグへ反映
- Audit Logs + Monitoring → アクセス履歴の永続化とリアルタイム異常検知
この 5 つのブロックを 「有効化 → 設定 → 自動保護 → 監査」 のサイクルで構築すれば、BigQuery に求められる 検索性・可視化・最小権限・自動保護・証跡 を一括で満たすデータガバナンス基盤が完成します。
次のステップ
1. 本稿の手順を踏んで 開発環境 に構築し、テストユーザーで条件付きロールとポリシータグの動作確認。
2. スキャン対象となるテーブル・InfoType を実運用に合わせて拡張。
3. 定期的（例：月次）に チェックリスト を実行し、変更があれば IAM ポリシーや DLP 設定を更新。
本ガイドは2024年4月時点の GCP UI/CLI の仕様に基づいています。機能追加や構文変更がある場合は公式ドキュメントをご確認ください。
スポンサードリンク