BigQuery Sharing（旧Analytics Hub）の権限まわりのポイントをまとめてみた
はじめに
お疲れ様です、データ事業本部の小高です。
Google Cloudの同組織内のプロジェクト間のデータ連携で、BigQuery Sharing（旧Analytics Hub）を利用できるか試してみたので、気になったポイントをまとめてみました。
BigQuery Sharingの基本的な使い方については以下のブログで丁寧に解説されていますので、そちらを参照してください。
本記事では、上記ブログの内容を前提として、BigQuery Sharingの権限制御の仕組みやリンク済みデータセット特有の挙動についてまとめます。
BigQuery Sharingの概要
BigQuery Sharingは、組織内外でBigQueryデータセットを共有できるサービスです。
引用: Introduction to BigQuery sharing | Google Cloud
主要な用語を簡単に整理しておきます。
| 用語 | 説明 |
|---|---|
| Exchange（エクスチェンジ） | Listingをまとめる論理的なグループ。限定公開/一般公開を選択可能 |
| Listing（リスティング） | 共有対象のデータセットと1対1で対応する共有単位 |
| リンク済みデータセット | Subscriberがサブスクライブした際にSubscriber側プロジェクトに作成される読み取り専用のデータセット |
| Publisher | データを提供する側 |
| Subscriber | データを受け取る側 |
詳しくは公式ドキュメントや上述のブログを参照してください。
使ってみて分かったこと
1. Exchange/Listing単位でプリンシパル毎にアクセス制御ができる
BigQuery Sharingでは、Exchange単位・Listing単位のそれぞれでsubscriberロールを付与することでアクセス制御が可能です。
subscriberロールを付与した場合
- ExchangeにSubscriber側ユーザーの
subscriberロールを付与
- Listingにも権限が継承される
- 問題なくサブスクライブ成功
subscriberロールを削除した場合
- Exchangeから
subscriberロールを削除
- Listingが一覧に表示されず、選択すらできない
省略しますが、Listing単位でも同様の結果になりました。
今回はプリンシパルにユーザーを指定しましたが、グループを指定すれば「このExchangeにはA部門のグループだけ」「このListingにはBチームだけ」といった柔軟な権限制御が可能です。
2. 承認済みデータセットとの違い — 主導権がSubscriber側にある
BigQueryのクロスプロジェクト共有にはもう一つ、承認済みデータセット（Authorized Dataset）を使う方法があります。BigQuery Sharingとの大きな違いは共有の主導権がどちら側にあるかです。
承認済みデータセットに関しては下記のブログを参照ください。
| 観点 | 承認済みデータセット | BigQuery Sharing |
|---|---|---|
| 共有の主導権 | Publisher側（承認設定を行う） | Subscriber側（自ら購読登録する） |
| 共有の起点 | Publisher側がデータセットに承認を付与 | Subscriber側がListingをサブスクライブ |
| Subscriber側に必要なBigQuery IAM | BigQueryデータ閲覧者 + BigQueryユーザー |
BigQueryユーザーのみ |
| 向いているケース | 共有先が少数で、Publisher側が厳密に管理したい場合 | 共有先が多く、Subscriber側にセルフサービスで利用させたい場合 |
承認済みデータセットはPublisher側が「このデータセットへのアクセスを許可する」と設定する仕組みのため、Subscriber側にもデータ閲覧権限（BigQueryデータ閲覧者）の付与が必要です。
一方、BigQuery SharingではSubscriber側が自らサブスクライブするという形をとります。この仕組みの違いがあるため、サブスクリプション自体がアクセス許可の役割を果たしており、別途データ閲覧権限を付与しなくてもクエリが実行できるのではないかと推測しています。
使い分けとしては、Publisher側が「誰に何を見せるか」を細かくコントロールしたい場合は承認済みデータセット、Publisher側のIAM管理を増やさずにSubscriber側に自分で購読してもらいたい場合はBigQuery Sharingが合っていると思います。
3. リンク済みデータセットのクエリにBigQueryデータ閲覧者権限が不要
実際に確認してみたところ、やはりBigQueryデータ閲覧者なしでクエリが実行できました。
通常のBigQuery内のテーブルに対してクエリを実行するには、クエリの実行権限であるBigQueryユーザー（bigquery.user）に加えてデータ閲覧権限であるBigQueryデータ閲覧者が必要です。しかし、リンク済みデータセット内のテーブルに対してはBigQueryユーザーだけで問題ありませんでした。
Subscriber側ユーザーにBigQueryユーザーのみを付与した状態で確認しました。
ロールの詳細はBigQuery のアクセス制御 | Google Cloudを参照してください。
- Subscriber側ユーザーに
BigQueryユーザー（bigquery.user）のみを付与
- リンク済みデータセットに対してクエリを実行し、成功
サブスクライブした時点でリンク済みデータセットへのデータアクセスが暗黙的に許可される仕組みのようです。つまり、サブスクリプション自体がアクセス許可の役割を果たしているということになります。
そのため、Subscriber側ユーザーにPublisher側プロジェクトのBigQuery関連IAMロール（BigQueryデータ閲覧者など）を付与する必要がありません。
なお、リンク済みデータセットは読み取り専用なので、INSERT/UPDATE/DELETEを実行するとエラーになります。
BigQuery Sharingの制限事項
BigQuery Sharingの制限事項を公式ドキュメントからいくつかピックアップしました。
| 留意事項 | 詳細 |
|---|---|
| サブスクリプション数の上限 | 1つのListingあたり最大1,000個のリンク済みデータセット（サブスクリプション） |
| Viewの閲覧にはPublisher側の権限が必要 | リンク済みデータセット内のViewを参照する場合、Publisher側データセットの閲覧権限が必要。ただし承認済みView（Authorized View）であれば閲覧可能 |
| リンク済みデータセット内の個別テーブルへのIAMロール設定不可 | テーブル単位での権限制御はできない |
| リンク済みデータセット内のテーブルへのIAMタグ設定不可 | タグベースの細かい制御もできない |
特にViewの扱いには注意が必要です。リンク済みデータセット内のViewが参照する元テーブルへのアクセス権が必要になるため、承認済みViewを使うか、View参照先のデータセットの閲覧権限をSubscriberに付与する必要があります。
参考: Introduction to BigQuery sharing#limitations | Google Cloud
まとめ
今回は、BigQuery Sharingの権限制御の仕組みについてまとめました。
ポイントは以下の通りです：
- Exchange/Listing単位の権限制御: プリンシパル毎に
subscriberロールを付与することで、購読の可否を柔軟に制御できる - 承認済みデータセットとの違い: BigQuery Sharingは共有の主導権がSubscriber側にあり、サブスクリプション自体がアクセス許可として機能する
- リンク済みデータセットは
BigQueryユーザー権限だけでクエリ可能: 上記の仕組みにより、通常のデータセットと異なりBigQueryデータ閲覧者は不要
BigQuery Sharingを検討している方の参考になれば幸いです。
