テーブルへのアクセス制御の概要

このページでは、BigQuery テーブル ACL の概要について説明します。

BigQuery テーブル ACL では、テーブルやビューなどのリソースにテーブルレベルの権限を設定できます。テーブルレベルの権限により、データまたはビューにアクセスできるユーザー、グループ、サービス アカウントが決まります。ユーザーに完全なデータセットへのアクセス権を与えることなく、特定のテーブルまたはビューへのアクセス権を付与できます。たとえば、ユーザーに BigQuery データ閲覧者（roles/bigquery.dataViewer）のロールを付与すると、対象のユーザーはデータセット全体に対するアクセス権がなくてもテーブルまたはビューのみにクエリを実行できます。

Identity and Access Management ポリシーを使用したアクセス制御

Identity and Access Management（IAM）ポリシーを使用して、テーブルまたはビューに対するアクセス制御ポリシーを構成できます。

テーブルまたはビューの IAM ポリシーを表示する

テーブルまたはビューを作成すると、次の方法で IAM ポリシーを表示できます。

テーブルまたはビューの IAM ポリシーを設定する

次の方法でリソースに対するアクセス制御ポリシーを設定または更新できます。

ビューでは、BigQuery テーブル ACL を使用して共有した他のソーステーブルとビューを参照することもできます。 BigQuery テーブル ACL によるアクセス権は追加型です。BigQuery テーブル ACL は deny 権限をサポートしていません。付加的なアクセス制御の詳細については、ビューへのアクセスの制御をご覧ください。

ユーザーが特定のテーブルまたはビューにアクセス可能かどうかをテストするには、tables.testIamPermissions メソッドを使用します。詳細については、権限のテストをご覧ください。

テーブルおよびビューへのアクセス ポリシーを設定する方法については、テーブルおよびビューへのアクセスの制御をご覧ください。

使用例

Alice はある会社のデータオーナーで、フランチャイズ店舗のオーナーと inventory テーブルを共有しようとしています。このテーブルは、Alice がフランチャイズ店舗のオーナーと共有したくない他のテーブルを含むデータセットの中にあります。

Bob はフランチャイズ店舗のオーナーです。Alice は bq コマンドライン ツールを使用して、Bob を含むフランチャイズ店舗のオーナーに inventory テーブルの BigQuery データ閲覧者（roles/bigquery.dataViewer）のロールを付与します。これで、Bob はデータセット全体にアクセスせずに inventory テーブルを直接クエリできるようになります。

Bob がテーブルのリストを確認できるように、Alice はデータセットに対する bigquery.tables.list 権限を Bob に付与します。データセットに対する bigquery.tables.list 権限が付与されている場合、Bob はアクセス可能なテーブルだけでなく、データセット内のすべてのテーブルのリストを確認できます。BigQuery メタデータ閲覧者（roles/bigquery.metadataViewer）のロールには bigquery.tables.list 権限が含まれています。

IAM ポリシー

テーブルレベルのアクセス制御は IAM 上に構築されます。IAM では、ポリシーを設定して誰（どのユーザー）に、どのリソースに対するどのアクセス権（ロール）を付与するかを制御できます。ポリシーとはどのプリンシパルにどのロールを付与するかを定義するもので、リソースに関連付けられています。プリンシパルがリソースにアクセスしようとすると、IAM はリソースのポリシーをチェックし、そのアクションが許可されているかどうかを確認します。

BigQuery テーブル ACL の場合、リソースは BigQuery テーブルであり、プリンシパルはテーブルのユーザーです。

以下の例は、次のロールを含むポリシーを示しています。

  • alice@example.com に BigQuery データオーナー（roles/bigquery.dataOwner）のロールが付与されている。

  • bob@example.com に BigQuery データ閲覧者（roles/bigquery.dataViewer）のロールが付与されている。

{
  "bindings":[
    {
      "members":[
        "user:alice@example.com"
      ],
      "role":"roles/bigquery.dataOwner"
    },
    {
      "members":[
        "user:bob@example.com"
      ],
      "role":"roles/bigquery.dataViewer"
    }
  ],
  "etag":"ABAC",
  "version":1
}

IAM ポリシーの詳細については、ポリシーについてをご覧ください。

BigQuery テーブル ACL 権限

テーブルまたはビューへのアクセス権を設定または変更するには、bigquery.tables.setIamPolicy 権限が必要です。次の BigQuery の事前定義ロールには、bigquery.tables.setIamPolicy 権限が含まれています。

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

テーブルまたはビューに設定されているアクセス権を取得するには、bigquery.tables.getIamPolicy 権限が必要です。次の BigQuery の事前定義ロールには、bigquery.tables.getIamPolicy 権限が含まれています。

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

ポリシー変更のタイムラグ

通常、ポリシーの変更は 60 秒以内に有効になります。ただし、状況によっては、変更がシステム全体に反映されるまでに最大 7 分かかることもあります。詳細については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。また、このドキュメントのキャッシュへの影響もご覧ください。

キャッシュへの影響

キャッシュが有効になっている場合、アカウントがテーブルにアクセスできなくなった後に、アカウントで以前に承認されたクエリ結果が表示される場合があります。具体的には、ユーザーが以前にクエリを正常に実行した後で、そのユーザーのアクセス権を削除した場合に、クエリ結果キャッシュから結果を取得できる場合があります。BigQuery は承認されたアクセスのみをキャッシュに保存します。キャッシュに保存されるのは数分間です。

タイムトラベルへの影響

FOR SYSTEM_TIME AS OF 句は BigQuery の「タイムトラベル」機能であり、最大 7 日前のデータを取得できます。この機能を使用すると、BigQuery は現在のテーブル ACL をリクエストに適用します。以前にテーブルにアクセスしたことがあるが、そのアクセスが削除されている場合、そのテーブルの以前のバージョンにはアクセスできません。

テーブルのコピー時の影響

新しいテーブルにデータをコピーしても、コピー元テーブルのテーブル ACL は自動的にコピーされません。コピーにより作成された新しいテーブルにテーブル ACL が必要な場合は、新しいテーブルにテーブル ACL を明示的に設定する必要があります。

承認済みビューとの比較

BigQuery では、承認済みビューを使用してアクセスすることもできます。承認済みビューを使用すると、元のテーブルへのアクセス権がないユーザーでも、クエリの結果を特定のユーザーやグループと共有できます。承認済みビューによるアクセス権は常に読み取り専用です。

たとえば、承認済みビュー dept_view を使用すると、ユーザー joe@example.com は部門ごとの平均給与を確認できるようになりますが、元となる salary データセットにある各個人の給与は確認できません。dept_view にデータソースへのアクセスが許可されている場合、joe@example.com には dept_view に対する権限のみが必要です。

通常のビューと承認済みビューの主な相違点は、ソーステーブル データへのアクセスを制御するために使用される権限です。ソーステーブル データへの通常のビューのアクセスは、エンドユーザーの権限に従ってチェックされます。承認済みビューのソーステーブル データへのアクセスは、承認済みビューの独自の権限を使用してチェックされます。

BigQuery テーブル ACL が追加されたことで、テーブルへのアクセスには次のオプションを利用できます。

  • すべてのソーステーブルを含むデータセットをユーザーと共有する。このオプションは、データセット レベルで設定される IAM アクセス制御です。
  • ユーザーが IAM アクセス権を割り当てられていないソースデータにアクセスするための承認済みビューを作成する。ソースデータには、ユーザーの権限ではなく、承認済みビュー独自の権限に基づいてアクセスします。このオプションは、承認済みビューの機能です。
  • 親データセット内のすべてのデータを共有することなく、テーブルまたはビューを特定のユーザーと共有する。このオプションは BigQuery テーブル ACL の機能です。

他の BigQuery 機能との互換性

IAM アクセスモデルでは、権限は追加型です。リソース階層で説明されているように、リソース権限は親リソースから継承されます。リソースに権限が追加されると、追加のアクセス権が付与されます。テーブル ACL ではアクセス権の追加のみできます。データセットや Google Cloud プロジェクトへのアクセス権の削除はできません。BigQuery 機能がテーブルレベルのアクセスを確認できない場合、既存のデータセット レベルのアクセス制御にフォールバックします。そのため、BigQuery テーブル ACL は他の BigQuery 機能との互換性があります。

VPC Service Controls との互換性

VPC Service Controls は IAM を使用して、BigQuery や Cloud Storage などのサービスへのアクセスを制御します。BigQuery テーブル ACL は、IAM を使用して個々の BigQuery テーブルに対するアクセス制御をより細かく行います。IAM は補完的な方法で使用されるため、VPC Service Controls と BigQuery テーブル ACL には互換性があります。

監査ログ

テーブルまたはビューへのポリシーの設定は管理アクティビティです。管理アクティビティは常にロギングされます。ロギングされたアクティビティを確認するには、Cloud Audit Logs を使用して、"google.iam.v1.IAMPolicy.SetIamPolicy" に設定された methodName の発生を確認します。

テーブル ACL ロギング

制限事項

  • テーブルレベルでの承認済みビューはサポートされていません。承認済みビューには、データセット全体に対するアクセスのみが許可されます。ただし、BigQuery テーブル ACL を使用して、個々のテーブルまたはビューへのアクセス権をユーザーに付与できます。

  • 現在、元になるデータセットなしでテーブルが直接共有されている場合、共有テーブルは Data Catalog の検索結果に表示されません。

  • ワイルドカード テーブルに対してクエリを実行する場合、テーブルレベルのアクセス制御はチェックされません。クエリでテーブル ワイルドカードを使用して、ユーザーがアクセスするテーブルを共有する場合は、そのテーブルを含むデータセットへのアクセス権をユーザーに付与する必要があります。

  • ワイルドカード テーブルと同様に、INFORMATION_SCHEMA データセットの配下にあるテーブルはテーブルレベルのアクセス制御の対象ではありません。データセット レベルの権限も必要です。

次のステップ