はじめに
こんにちは！GA4 (Google Analytics 4), GSC (Google Search Console), Google Ads といったマーケティングデータを BigQuery に集約し、データ分析基盤として活用する動きが活発ですね。データを一元化することで、部門横断的な分析や深いインサイト獲得が期待できます。
私も最近、これらのデータを BigQuery プロジェクトに集約し、社内の別プロジェクトチーム（例: マーケティング分析チーム）とデータを共有しようと試みました。
しかし、GCP を組織 (Organization) アカウントで利用している環境では、以前個人アカウントで経験したようなシンプルなプロジェクト単位の共有が、そのままでは推奨されない、あるいは場合によっては実行できない状況に直面しました。
結論として、組織アカウント環境下での BigQuery データ共有は、「データセット単位」での権限付与がセキュリティとガバナンスの観点から強く推奨される基本であり、多くのケースでこれが最適な方法です。
この記事では、その理由と具体的な方法に加え、「組織ポリシーを変更すればプロジェクト単位でも共有できるのでは？」という疑問にも触れながら、なぜそれでもデータセット単位が推奨されるのかを解説します。
やろうとしたこと：複数データソースを集約したプロジェクトの共有
まずは背景から。以下のような BigQuery プロジェクトを構築しました。
-
GCP プロジェクト:
marketing-data-lake(仮名) -
データセット:
-
ga4_data: GA4 からエクスポートされたデータ -
gsc_data: Search Console のデータ (例: API経由) -
ads_data: Google Ads から転送されたデータ -
aggregated_data: 上記データを加工・集計した結果
-
目標は、この marketing-data-lake プロジェクトのデータをマーケティング分析チームに共有し、分析に活用してもらうことです。個人アカウントの感覚だと、プロジェクトに roles/bigquery.dataViewer を付与すれば済む話でした。
直面した壁：なぜ組織アカウントではプロジェクト単位共有が推奨されないのか？
組織アカウント環境でプロジェクト単位の共有を検討した際、以下の点が大きな懸念となりました。
1. 権限が広すぎる！ (最小権限の原則の違反)
これが最大の理由です。プロジェクトレベルの権限（例: roles/bigquery.dataViewer, roles/bigquery.dataEditor）は、プロジェクト内の全てのデータセットへのアクセスを許可します。
分析チームが ads_data の詳細なコストデータを見る必要がない場合でも、プロジェクト単位で権限を与えると見えてしまいます。これは組織で最も重要視されるべき「最小権限の原則」に反し、不要な情報漏洩や誤操作のリスクを高めます。必要なデータに必要な人だけがアクセスできる状態が理想です。
2. 管理の複雑化と将来的なリスク
プロジェクトに新しいデータセット（例: CRMデータ）が追加された場合、プロジェクト単位で権限を持つ全員が自動的にその新しいデータセットにもアクセスできてしまいます。意図しないアクセス権の付与を防ぐためには、常に権限の見直しが必要となり、管理が煩雑になります。
3. 組織ポリシーによる制限の可能性
多くの組織では、セキュリティ ガバナンスを強化するために GCP の「組織ポリシー」を設定しています。
-
具体例:
-
constraints/iam.allowedPolicyMemberDomains: 特定ドメインのユーザーにしか権限付与を許可しない。 -
constraints/iam.denyAdminMembers: プロジェクトに対する広範な管理者権限の付与を制限する。 - 特定の IAM ロールの利用を制限するポリシーなど。
-
これらのポリシーによって、そもそもプロジェクトレベルでの広範な権限付与が、組織のルールとしてデフォルトで禁止または制限されている場合があります。
「組織ポリシーを変更すればプロジェクト単位で共有できるのでは？」という疑問
ここで、「組織ポリシーを変更して制限を緩和すれば、プロジェクト単位で共有できるのではないか？」と考えるかもしれません。
答えは「技術的には可能だが、推奨されない」です。
- 技術的な可能性: 組織の管理者は、特定の組織ポリシー（例えば IAM 関連の制約）を調整・無効化することで、プロジェクト単位での権限付与を許可するように変更すること自体は可能です。
-
なぜ推奨されないか:
- 組織全体のセキュリティレベル低下: 組織ポリシーは、組織全体のセキュリティとガバナンスのベースラインを定義しています。特定のプロジェクトのために安易にポリシーを緩和すると、他のプロジェクトにも影響が及ぶ可能性があり、組織全体のセキュリティレベルを低下させるリスクがあります。
- 変更の難易度と承認プロセス: 組織ポリシーの変更は、通常、セキュリティ部門やインフラ管理部門などの承認が必要であり、個別のプロジェクトの都合だけで簡単に変更できるものではありません。厳格な変更管理プロセスが求められます。
- 根本的な問題は解決しない: たとえポリシーを変更してプロジェクト単位の共有を可能にしたとしても、「権限が広すぎる（最小権限の原則違反）」や「管理の複雑化」といった根本的な問題は解決しません。
特別な理由や厳格なリスク評価、そして適切な承認プロセスがない限り、組織ポリシーを変更してプロジェクト単位の共有を実現することは避けるべきアプローチです。
解決策であり推奨策：データセット単位でのアクセス制御
結局のところ、組織アカウント環境における最も安全で管理しやすく、推奨される解決策は、BigQuery のデータセット単位でのアクセス制御です。
個々のデータセットに対して IAM ポリシーを設定することで、きめ細かな権限管理を実現します。
今回の設定例:
-
marketing-data-lakeプロジェクト自体には、分析チームに BigQuery 関連のロールは原則付与しない。 -
ga4_data,gsc_data,aggregated_dataの各データセットに対して、分析チームの Google グループにroles/bigquery.dataViewerを付与。 -
ads_dataデータセットには、分析チームにはロールを付与しない。
# 例: bq コマンドでデータセットに閲覧者ロールを付与
bq add-iam-policy-binding --member='group:analyst-team@example.com' --role='roles/bigquery.dataViewer' 'marketing-data-lake:ga4_data'
bq add-iam-policy-binding --member='group:analyst-team@example.com' --role='roles/bigquery.dataViewer' 'marketing-data-lake:gsc_data'
bq add-iam-policy-binding --member='group:analyst-team@example.com' --role='roles/bigquery.dataViewer' 'marketing-data-lake:aggregated_data'
この方法なら、最小権限の原則を守りつつ、安全かつ明確にデータ共有の目的を達成できます。
まとめ
GA4, GSC, Ads などのデータを BigQuery で一元管理し、組織内で共有する場合、以下の点を理解しておくことが重要です。
-
組織アカウントでは、データセット単位での権限付与が基本であり、強く推奨される。
- これにより、最小権限の原則を守り、セキュリティリスクを低減し、管理を容易にできる。
- プロジェクト単位での共有は、権限が広すぎるため、通常は避けるべき。
- 組織ポリシーによって、プロジェクト単位の共有がデフォルトで制限されている場合がある。
- 組織ポリシーを変更すればプロジェクト単位共有も技術的には可能だが、組織全体のセキュリティリスクを高める可能性があり、特別な理由と厳格なプロセスがない限り推奨されない。
BigQuery の強力な機能を安全に活用するためにも、組織のルールとセキュリティのベストプラクティスに従い、データセット単位でのアクセス制御を基本とした運用を心がけましょう。