テーブル アクセス ポリシーの概要

このドキュメントでは、テーブル アクセス ポリシーの概要について説明します。

テーブル アクセス ポリシーを使用すると、テーブルやビューなどのリソースに対してテーブルレベルの権限を設定できます。テーブルレベルの権限により、データまたはビューにアクセスできるユーザー、グループ、サービス アカウントが決定されます。たとえば、BigQuery データ閲覧者の Identity and Access Management（IAM）のロール（roles/bigquery.dataViewer）を付与して、データセットへのフルアクセス権を付与せずに、ユーザーがテーブルまたはビューのみをクエリできるように設定可能です。

テーブル アクセス ポリシーを使用したアクセス制御

テーブル アクセス ポリシーは、Identity and Access Management（IAM）ポリシーを基盤として構築されています。

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

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

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

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

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

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

ビューでは、テーブル アクセス ポリシーを使用して共有した他のソーステーブルとビューを参照することもできます。テーブル アクセス ポリシーを使用したアクセス権は付加的なアクセス権です。テーブル アクセス ポリシーでは、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 ポリシーの例

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

  • 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.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 によって現在のアクセス ポリシーがリクエストに適用されます。以前にテーブルにアクセスしたことがあるが、そのアクセスが削除されている場合、そのテーブルの以前のバージョンにはアクセスできません。

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

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

承認済みビューとの比較

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

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

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

テーブル アクセス ポリシーを使用する場合、テーブル アクセスには次のオプションがあります。

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

他の BigQuery 機能との互換性

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

VPC Service Controls との互換性

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

監査ロギング

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

テーブル アクセス ポリシーのロギング

制限事項

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

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

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

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

次のステップ