G-genの杉村です。BigQuery への認証・認可は Cloud IAM によって制御されますが、その仕組みは複雑です。当記事では、仕組みを詳細に解説します。

はじめに

BigQuery と認証・認可

Google Cloud（旧称 GCP）のデータウェアハウスサービスである BigQuery では、認証・認可が Identity and Access Management（IAM）によって制御されます。

Google Cloud の IAM の仕組み自体が難しいことに加えて、BigQuery ではジョブ実行権限とデータ取得・編集権限が別れていたり、「基本ロール」には特殊な仕組みで権限が与えられていたり、と難解です。

当記事では、実環境での検証結果も交えて解説します。

IAM の基本概念

まずは Google Cloud の IAM の基本的な仕組みを理解する必要があります。本投稿では以下の記事の内容が理解されている前提で記載しておりますので、先にご参照ください。

特に「リソースの持つ許可ポリシー」「ロール」「継承」などの用語理解が必須です。

blog.g-gen.co.jp

BigQuery 関連の IAM 権限の理解

ジョブ実行とデータアクセス

BigQuery のジョブとは、BigQuery のコンピューティングリソースを使って行われる以下のような操作を指します。

クエリ（テーブルの読み取り、書き込み）
ロード（テーブルへのデータ投入）
エクスポート（Cloud Storage バケットなどにデータを出力）
コピー（テーブルを複製する）

これらの操作がユーザーやプログラムにより行われると、ジョブが作成され、バックグラウンドで処理が行われます。例として、コンソールに SQL を入力して実行したり、bq コマンドによって Cloud Storage からのデータロードなどを行う際に、ジョブが実行されます。

参考 : ジョブを管理する

BigQuery では、この「ジョブを実行する権限」と「テーブルのデータにアクセスする権限」が区別されています。

普段仕事で使うパソコンに例えると、パソコンにログインをする権限と、ファイルサーバへのアクセス権限とは別になっている、というようなイメージです。

別れている理由は、以下の例を考えると理解しやすくなります。

Google が公開しているパブリックデータセットを使って分析を行うケースを考えます。データセットへのアクセス権限は全世界に公開されており、データの保管料金は、データを保持している会社（プロジェクト）に課金されています。しかしクエリジョブはデータ利用者側の Google Cloud プロジェクトに投入する必要があり、コンピュート料金もデータを利用する側が負担します。

このようにデータを保管するユーザーと、クエリを実行するユーザーがわかれているとき、IAM 権限が別々に管理されているために、責任範囲や費用負担を分割することができます。

ジョブ実行権限

ジョブ実行関連の IAM 権限には bigquery.jobs.create、bigquery.jobs.get、bigquery.jobs.list といったものがあります。

ジョブを実行するには bigquery.jobs.create の権限が必要です。この権限は、以下のような事前定義ロールに含まれています。

BigQuery 管理者（roles/bigquery.admin）
BigQuery ジョブユーザー（roles/bigquery.jobUser）
BigQuery ユーザー（roles/bigquery.user）
BigQuery Studio ユーザー（roles/bigquery.studioUser）

これらのロールは、プロジェクトレベル以上（組織、フォルダ、プロジェクト）で付与する必要があります。ジョブはプロジェクトの API に対して投入するものなので、これらのロールをデータセットのレベルに付与しても効果がないか、ロールによっては付与できない仕様になっています。

ただし、ジョブの実行権限だけを持っていても、データにアクセスすることはできません。次に記載するデータへのアクセス権限が必要です。

データへのアクセス権限

読み取り権限

BigQuery のテーブルへクエリ等を行うには、ジョブ実行権限に加えて、データへのアクセス権限が必要です。先ほどの仕事用パソコンの例えを使うと、こちらはファイルサーバへのアクセス権限です。

テーブル内のデータに読み取りアクセスするには、bigquery.tables.getData の権限が必要です。この権限は、以下のような事前定義ロールに含まれています。

BigQuery 管理者（roles/bigquery.admin）
BigQuery データオーナー（roles/bigquery.dataOwner）
BigQuery データ編集者（roles/bigquery.dataEditor）
BigQuery データ閲覧者（roles/bigquery.dataViewer）

これらのロールはプロジェクトレベル、データセットレベル、あるいはテーブルレベルで付与することができます。親リソースにロールを付与すれば、その配下にある子リソースすべてに権限が継承されます。

例えばあるデータセット内のデータに読み取りクエリを実行したい場合、そのユーザーのアカウントに、プロジェクトレベルで BigQuery ジョブユーザー（roles/bigquery.jobUser）を付与するのに加えて、該当のデータセットレベルで BigQuery データ閲覧者（roles/bigquery.dataViewer）を付与します。これにより、このユーザーはプロジェクトレベルでのジョブ実行権限と、データセットレベルでのデータ読み取り権限を得ることになり、SELECT 文等を実行することができます。

読み取り権限の検証

「ジョブ実行権限はプロジェクトレベルで付与する必要がある」そして「データへのアクセス権限はデータセットレベルもしくはテーブルレベルで付与する」と記載したことについて、検証します。

BigQuery ジョブユーザー（roles/bigquery.jobUser）ロールはデータセット単位では付与できない仕様のため、上記の表では N/A となっています。

表のとおり、プロジェクトレベルにジョブ実行権限がない場合にはクエリが実行不可（N）という結果になりました。

またジョブ実行権限さえあれば、データ読み取り権限はデータセットレベルで付与することでデータが読み取れる、という結果が確かめられました。なお、データセットレベルでなく、テーブルレベルで権限を付与することでも、データを読み取ることができます。

書き込み権限

書き込み権限について、基本的な考え方は読み取り権限と同様です。

書き込みアクセスに必要な権限は bigquery.tables.updateData です。この権限は、以下のような事前定義ロールに含まれています。

BigQuery 管理者（roles/bigquery.admin）
BigQuery データオーナー（roles/bigquery.dataOwner）
BigQuery データ編集者（roles/bigquery.dataEditor）

メタデータへのアクセス権限

メタデータはデータセットやテーブルの持つ付随的な属性情報です。テーブルのスキーマ情報などがこれに当たります。

仕事場のパソコンの例えを使うと、ファイルサーバのデータ容量の使用状況やディスクのドライブ名、またファイルシステムの設定値などが当たります。

データセットのメタデータに対する権限として bigquery.datasets.get、bigquery.datasets.update があり、テーブルのメタデータに対する権限として bigquery.tables.get、bigquery.tables.update などがあります。

メタデータの閲覧・編集権限があれば、テーブル名やカラム情報を得ることができますが、テーブル内のデータ（レコード）を閲覧したり、編集することはできません。

事前定義ロールである BigQuery データ編集者（roles/bigquery.dataEditor）や BigQuery データ閲覧者（roles/bigquery.dataViewer）などは、データに対する権限に加えて、メタデータに対する権限も持っています。

一方で、BigQuery メタデータ閲覧者（roles/bigquery.metadataViewer）ロールはメタデータに対する読み取り権限を持っていますがデータ自体への権限はないので、 BigQuery 基盤の管理者・運用者などが使うことが想定されます。

ロールが持つ IAM 権限

どの IAM ロールがどのような権限を持っているかを確認したい場合、以下のドキュメントを参照します。

テキストボックスに権限名を入力して検索することで、ある権限を持つロールの一覧が確認できます。また逆に、ロール名を検索することで、そのロールが持つ権限の一覧を確認できます。

参考 : IAM roles and permissions index

ユースケース別 IAM 設定

プロジェクトのすべてのデータセットに対する閲覧権限を与えたい

設定

付与対象リソース
- プロジェクト
付与する IAM ロール
- BigQuery Studio ユーザー（roles/bigquery.studioUser）
- BigQuery データ閲覧者（roles/bigquery.dataViewer）

説明

プロジェクトレベルで、Google アカウントに対して上記の2つのロールを付与することで、そのアカウントはプロジェクト内のすべてのデータセット・テーブルに対して読み取りクエリを実行することができるようになります。

BigQuery Studio ユーザー（roles/bigquery.studioUser）ロールをプロジェクトレベルで設定することにより、アカウントは BigQuery ジョブを実行する権限を得ます。

BigQuery Studio ユーザーロールの代わりに BigQuery ジョブユーザー（roles/bigquery.jobUser）ロールでも構いませんが、BigQuery Studio ユーザーロールを付与することで Gemini in BigQuery を含む、BigQuery Studio（BigQuery の Web コンソール）のほとんどすべての機能を利用することができます。Gemini in BigQuery は生成 AI が SQL コーディングの補助等をしてくれる機能であり、制限付きながら無償で利用できます。

もしロールの付与対象が人間のユーザーではなくサービスアカウントである場合、BigQuery Studio ユーザーロールよりも BigQuery ジョブユーザーロールの方が適しています。

上記に加え、BigQuery データ閲覧者（roles/bigquery.dataViewer）をプロジェクトレベルに設定することで、アカウントはプロジェクト内の全てのデータセットとテーブルに対して閲覧権限を持ちます。

特定のデータセットにだけ閲覧・編集権限を与えたい

設定

IAM 設定 1
- 付与対象リソース
  - プロジェクト
- 付与する IAM ロール
  - BigQuery Studio ユーザー（roles/bigquery.studioUser）
IAM 設定 2
- 付与対象リソース
  - データセット
- 付与する IAM ロール
  - BigQuery データ編集者（roles/bigquery.dataEditor）

説明

上記の IAM 設定 1 と 2 の両方、すなわちプロジェクトレベルとデータセットレベルの両方で、アカウントに対してロールを付与することで、特定のデータセットに対してのみ、INSERT や UPDATE、SELECT の実行などデータの読み取り・編集権限を得ることができます。

BigQuery Studio ユーザー（roles/bigquery.studioUser）ロールなどをプロジェクトレベルで付与することで、アカウントはジョブを実行できるようになります。なお同ロールはデータセットレベルには付与できない仕様であり、必ずプロジェクトレベル以上にしか付与できません。

また BigQuery データ編集者（roles/bigquery.dataEditor）をデータセットレベルで付与することで、そのデータセットに対してのみ、データの編集権限を持つことができます。一方でプロジェクトレベルに設定すると、プロジェクト内の全てのデータセットとテーブルに対して編集権限を持つことができます。

特定のプロジェクトの BigQuery 全体管理者

設定

付与対象リソース
- プロジェクト
付与する IAM ロール
- BigQuery 管理者（roles/bigquery.admin）

説明

プロジェクトレベルで BigQuery 管理者（roles/bigquery.admin）ロールを付与すれば、そのアカウントはジョブの実行、データへのアクセス、データセットやテーブルの作成、など BigQuery に関する全ての操作を行うことができます。

BigQuery のデータを含むプロジェクト内の全リソースの閲覧権限を与えたい

設定

付与対象リソース
- プロジェクト
付与する IAM ロール
- 閲覧者（roles/viewer）

説明

ある Google アカウントが閲覧者（roles/viewer）ロールをプロジェクトレベルで持っていると、BigQuery の全データセット・テーブルのデータとメタデータを閲覧することができます。

閲覧者は、BigQuery 以外のほとんどすべての情報に対する閲覧権限も持つため、注意が必要です。

閲覧者ロールに関する考察

閲覧者（roles/viewer）ロールと BigQuery の関係性について、詳細に解説します。

閲覧者（roles/viewer）ロールの持つ BigQuery 関係の権限を一覧化すると、以下のようになります。

sugimura@cloudshell:~ (gcp-dev-yuma-sugimura)$ gcloud iam roles describe roles/viewer | grep bigquery
- bigquery.bireservations.get
- bigquery.capacityCommitments.get
- bigquery.capacityCommitments.list
- bigquery.config.get
- bigquery.connections.get
- bigquery.connections.getIamPolicy
- bigquery.connections.list
- bigquery.connections.use
- bigquery.datasets.get
- bigquery.datasets.getIamPolicy
- bigquery.jobs.create
- bigquery.jobs.get
- bigquery.jobs.list
- bigquery.models.export
- bigquery.models.getData
- bigquery.models.getMetadata
- bigquery.models.list
- bigquery.readsessions.create
- bigquery.readsessions.getData
- bigquery.readsessions.update
- bigquery.reservationAssignments.list
- bigquery.reservationAssignments.search
- bigquery.reservations.get
- bigquery.reservations.list
- bigquery.routines.get
- bigquery.routines.list
- bigquery.rowAccessPolicies.getIamPolicy
- bigquery.rowAccessPolicies.list
- bigquery.savedqueries.get
- bigquery.savedqueries.list
- bigquery.tables.createSnapshot
- bigquery.tables.getIamPolicy
- bigquery.transfers.get

上記から抜粋すると、BigQuery のテーブルに関する権限は以下の2つだけです。

- bigquery.tables.createSnapshot
- bigquery.tables.getIamPolicy

これでは、閲覧者ロールはテーブルのメタデータやデータに対するアクセス権限は持たないはずです。前述の通り、データにアクセスするには bigquery.tables.getData の権限が必要です。bigquery.jobs.create 権限はあるのでジョブ実行はできますが、テーブルのデータは読み取れず、Access Denied エラーになるはずです。

しかし実際には、テーブルのデータを取得することができます。これは、BigQuery が新規データセットに対してデフォルトで付与する、以下の設定が関係しています。

上のスクリーンショットの通り、プロジェクトレベルで閲覧者（roles/viewer）ロールが付与されている人は、データセットに対して BigQuery データ閲覧者（roles/bigquery.dataViewer）相当の権限を持つように設定されています。これは IAM の仕組みとは異なる、レガシーなアクセス権限の仕組みに起因しています。

これは、データセットを新規作成するときに自動で設定される、BigQuery 特有の設定です。これにより、閲覧者（roles/viewer）ロール自体は bigquery.tables.getData 権限を持っていないため、本来はデータにアクセスできないはずですが、データセット側の個別設定で BigQuery データ閲覧者（roles/bigquery.dataViewer）相当の権限を与えられていたためアクセスができるようになっています。

参考 : Basic roles and permissions

同様にプロジェクトレベルの オーナー（roles/owner）には BigQuery データオーナー（roles/bigquery.dataOwner）相当の権限が、プロジェクトレベルの編集者（roles/editor）には BigQuery データ編集者（roles/bigquery.dataEditor）権限が割り当てられます。

これらの自動で割り当てられる権限は、削除することも可能です。