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

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

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

テーブルまたはビューにアクセス制御を設定するには、Identity and Access Management(IAM)ポリシーを使用します。テーブルまたはビューを作成すると、次の方法でポリシーを設定できます。

  • bq set-iam-policy コマンドを使用する(bq コマンドライン ツール バージョン 2.0.50 以降)。
  • Google Cloud Console を使用する。
  • tables.setIamPolicy メソッドを呼び出す。

ビューは、BigQuery テーブル ACL を使用して共有した、他のソーステーブルおよびビューを参照することもできます。

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

BigQuery テーブル ACL によるアクセス権は追加型です。BigQuery テーブル ACL は deny 権限をサポートしていません。

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

使用例

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

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

Bob がアクセス権を持つテーブルのリストを Bob に見せる場合は、データセットに対する bigquery.tables.list 権限を Alice が 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 が追加されたことで、テーブルのアクセスには次のオプションがあります。

  • 基になるすべてのテーブルを含むデータセットをユーザーと共有する。このオプションはすでに存在しています。

  • ユーザーがアクセスできるデータセット内のビューに、ユーザーの権限ではなく、ビュー自身の権限で別のデータセットのデータにアクセスすることを許可する。このオプションは既存の承認済みビューの機能です。

  • 親データセットを共有せずに、特定のユーザーとテーブルまたはビューを共有する。このオプションは BigQuery テーブル ACL の機能です。

BigQuery では、別のテーブルのデータにビュー独自の権限でアクセスすることを承認できません。

他の 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 監査ログを使用して、"google.iam.v1.IAMPolicy.SetIamPolicy" に設定された methodName の発生を確認します。

テーブル ACL ロギング

制限事項

  • テーブルレベルの承認済みビューはサポートされていません。ただし、BigQuery テーブル ACL を使用して、既存のデータセット レベルの承認済みビューを共有できます。

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

  • ワイルドカード テーブルに対してクエリを実行する場合、テーブルレベルのアクセス制御はチェックされません。個々のワイルドカード テーブルにテーブルレベルのアクセス制御を設定しないでください。代わりに、データセット レベルでアクセス権を設定してください。

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

次のステップ