行レベルのセキュリティを使用する

このドキュメントでは、BigQuery で行レベルのセキュリティを使用して、テーブルの行レベルでデータへのアクセスを制限する方法について説明します。このドキュメントを読む前に、BigQuery の行レベルのセキュリティの概要で行レベルのセキュリティの概要を理解しておいてください。

行レベルのアクセス ポリシーを使用すると、次のタスクを行うことができます。

• テーブルの行レベルのアクセス ポリシーを作成または更新する。
• テーブルの行レベルのアクセス ポリシーを組み合わせる。
• テーブルの行レベルのアクセス ポリシーを一覧表示する。
• テーブルから行レベルのアクセス ポリシーを削除する。
• 行レベルのアクセス ポリシーを使用してテーブルにクエリを実行する。

始める前に

このドキュメントの各タスクを実行するために必要な権限をユーザーに与える Identity and Access Management（IAM）のロールを付与します。タスクの実行に必要な権限（存在する場合）は、タスクの「必要な権限」セクションに記載されています。

行レベルのアクセス ポリシーを作成または更新する

データ定義言語（DDL）ステートメントを使用して、BigQuery テーブルの行レベルのアクセス ポリシーを作成または更新できます。

必要な権限

BigQuery テーブルで行レベルのアクセス ポリシーを作成するには、次の IAM 権限が必要です。

• bigquery.rowAccessPolicies.create
• bigquery.rowAccessPolicies.setIamPolicy
• bigquery.tables.getData（ターゲット テーブルと、付与されたサブクエリ行レベルのアクセス ポリシーで参照されるテーブル）
• bigquery.jobs.create（DDL クエリジョブを実行するためのもの）

BigQuery テーブルで行レベルのアクセス ポリシーを更新するには、次の IAM 権限が必要です。

• bigquery.rowAccessPolicies.update
• bigquery.rowAccessPolicies.setIamPolicy
• bigquery.tables.getData（ターゲット テーブルと、付与されたサブクエリ行レベルのアクセス ポリシーで参照されるテーブル）
• bigquery.jobs.create（DDL クエリジョブを実行するためのもの）

次の事前定義された IAM ロールには、行レベルのアクセス ポリシーの作成と更新に必要な権限が含まれています。

• roles/bigquery.admin
• roles/bigquery.dataOwner

bigquery.filteredDataViewer ロール

行レベルのアクセス ポリシーが正常に作成されると、権限の対象者リストのメンバーに bigquery.filteredDataViewer ロールが自動的に付与されます。bigquery.filteredDataViewer ロールを使用すると、ポリシーのフィルタ式で定義された行を表示できます。Google Cloud コンソールでテーブルの行レベルのアクセス ポリシーを一覧表示すると、このロールはポリシーの付与リストのメンバーと一緒に表示されます。

bigquery.filteredDataViewer ロールを IAM とともに使用する場合は、行レベルのセキュリティに関するベスト プラクティスをご覧ください。

BigQuery での IAM のロールと権限について詳しくは、事前定義ロールと権限をご覧ください。

行レベルのアクセス ポリシーを作成または更新する

行レベルのアクセス ポリシーを作成または更新するには、次のいずれかの DDL ステートメントを使用します。

• CREATE ROW ACCESS POLICY は、新しい行レベルのアクセス ポリシーを作成します。

• CREATE ROW ACCESS POLICY IF NOT EXISTS は、指定されたテーブルに同じ名前の行レベルのアクセス ポリシーが存在しない場合に新しい行レベルのアクセス ポリシーを作成します。

• CREATE OR REPLACE ROW ACCESS POLICY ステートメントは、指定されたテーブルにある同じ名前の既存の行レベルのアクセス ポリシーを更新します。

  重要:

  • テーブルの行レベルのアクセス ポリシーには一意の名前を付ける必要があります。
  • WHERE 句と同様に、filter_expression は grantee_list のメンバーに対して表示するデータと一致します。
  • grantee_list リストがカンマ区切りのリストで、各項目が引用符で囲まれている場合は、一連のユーザーとグループを組み合わせることができます。
  • 行レベルのアクセス ポリシーを JSON 列に適用することはできません。行レベルのセキュリティに関するその他の制限事項については、制限事項をご覧ください。

例

新しい行アクセス ポリシーを作成します。このテーブルへのアクセスはユーザー [e-mail] に制限されています。region = 'APAC' の行のみが表示されます。

CREATE ROW ACCESS POLICY apac_filter
ON project.dataset.my_table
GRANT TO ('user:[e-mail]')
FILTER USING (region = 'APAC');

アクセス ポリシーを更新して、サービス アカウント [e-mail] に適用します。

CREATE OR REPLACE ROW ACCESS POLICY apac_filter
ON project.dataset.my_table
GRANT TO ('serviceAccount:[e-mail]')
FILTER USING (region = 'APAC');

ユーザーと 2 つのグループにアクセス権を付与する行アクセス ポリシーを作成します。

CREATE ROW ACCESS POLICY sales_us_filter
ON project.dataset.my_table
GRANT TO ('user:[e-mail]',
          'group:[e-mail]',
          'group:[e-mail]')
FILTER USING (region = 'US');

付与対象として allAuthenticatedUsers を使用して行アクセス ポリシーを作成する

CREATE ROW ACCESS POLICY us_filter
ON project.dataset.my_table
GRANT TO ('allAuthenticatedUsers')
FILTER USING (region = 'US');

現在のユーザーに基づくフィルタを使用して、行アクセス ポリシーを作成する

CREATE ROW ACCESS POLICY my_row_filter
ON dataset.my_table
GRANT TO ('domain:example.com')
FILTER USING (email = SESSION_USER());

ARRAY 型の列にフィルタを使用して行アクセス ポリシーを作成する

CREATE ROW ACCESS POLICY my_reports_filter
ON project.dataset.my_table
GRANT TO ('domain:example.com')
FILTER USING (SESSION_USER() IN UNNEST(reporting_chain));

サブクエリを使用して行アクセス ポリシーを作成し、複数のポリシーをユーザーごとに構成された単純なリージョン比較に置き換えます。

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

この機能に関するフィードバックやサポートのリクエストは、[e-mail] 宛てにメールでお送りください。

以下のテーブル lookup_table を例に取り上げます。

+-----------------+--------------+
|      email      |    region    |
+-----------------+--------------+
| [e-mail] | europe-west1 |
| [e-mail] | us-west1     |
| [e-mail] | us-west2     |
+-----------------+--------------+

CREATE OR REPLACE ROW ACCESS POLICY apac_filter
ON project.dataset.my_table
GRANT TO ('domain:example.com')
FILTER USING (region IN (
    SELECT
      region
    FROM
      lookup_table
    WHERE
      email = SESSION_USER()));

lookup_table にサブクエリを使用すると、複数の行アクセス ポリシーを作成する必要がなくなります。たとえば、上記のステートメントは、クエリ数が少ない次のステートメントと同じ結果を返します。

CREATE OR REPLACE ROW ACCESS POLICY apac_filter
ON project.dataset.my_table
GRANT TO ('user:[e-mail]')
FILTER USING (region = 'us-west1');

CREATE OR REPLACE ROW ACCESS POLICY apac_filter
ON project.dataset.my_table
GRANT TO ('user:[e-mail]')
FILTER USING (region IN 'us-west1', 'us-west2');

CREATE OR REPLACE ROW ACCESS POLICY apac_filter
ON project.dataset.my_table
GRANT TO ('user:[e-mail]')
FILTER USING (region = 'europe-west1');

構文と使用可能なオプションの詳細については、CREATE ROW ACCESS POLICY DDL ステートメントリファレンスをご覧ください。

行レベルのアクセス ポリシーを組み合わせる

2 つ以上の行レベルのアクセス ポリシーが、ユーザーまたはグループに同じテーブルへのアクセス権を付与する場合、そのユーザーまたはグループは、いずれかのポリシーの対象となるすべてのデータにアクセスできます。たとえば、次のポリシーは、ユーザーに my_table テーブル内の指定された行への [e-mail] アクセス権を付与します。

CREATE ROW ACCESS POLICY shoes
ON project.dataset.my_table
GRANT TO ('user:[e-mail]')
FILTER USING (product_category = 'shoes');

CREATE OR REPLACE ROW ACCESS POLICY blue_products
ON project.dataset.my_table
GRANT TO ('user:[e-mail]')
FILTER USING (color = 'blue');

上記の例では、ユーザー [e-mail] は、my_table テーブル内の product_category フィールドが shoes に設定されている行にアクセスでき、また [e-mail] は color フィールドが blue に設定されている行にもアクセスできます。たとえば、[e-mail] は赤色の靴と青色の車に関する情報を含む行にアクセスできます。

このアクセス権は、次の単一の行レベルのアクセス ポリシーによって提供されるアクセス権と同等です。

CREATE ROW ACCESS POLICY shoes_and_blue_products
ON project.dataset.my_table
GRANT TO ('user:[e-mail]')
FILTER USING (product_category = 'shoes' OR color = 'blue');

一方、複数の条件が true になることに依存するアクセスを指定するには、AND 演算子を含むフィルタを使用します。たとえば、次のような行レベルのアクセス ポリシーでは、product_category フィールドが shoes に設定され、color フィールドが blue に設定された行にのみ [e-mail] アクセス権を付与します。

CREATE ROW ACCESS POLICY blue_shoes
ON project.dataset.my_table
GRANT TO ('user:[e-mail]')
FILTER USING (product_category = 'shoes' AND color = 'blue');

上の行レベルのアクセス ポリシーを使用すると、[e-mail] は青色の靴に関する情報にアクセスできますが、赤い靴や青色の車に関する情報にはアクセスできません。

テーブルの行レベルのアクセス ポリシーを一覧表示する

テーブルに対するすべての行レベルのアクセス ポリシーを一覧表示するには、Google Cloud コンソール、bq コマンドライン ツール、または RowAccessPolicies.List API メソッドを使用します。

必要な権限

BigQuery テーブルで行レベルのアクセス ポリシーを一覧表示するには、bigquery.rowAccessPolicies.list IAM 権限が必要です。

BigQuery テーブルに行レベルのアクセス ポリシーのメンバーを表示するには、bigquery.rowAccessPolicies.getIamPolicy IAM 権限が必要です。

次の事前定義された IAM ロールには、行レベルのアクセス ポリシーを一覧表示するために必要な権限が含まれています。

• roles/bigquery.admin
• roles/bigquery.dataOwner

BigQuery での IAM のロールと権限について詳しくは、事前定義ロールと権限をご覧ください。

テーブルの行レベルのアクセス ポリシーを一覧表示する

行レベルのアクセス ポリシーを一覧表示するには、次のようにします。

コンソール

1. 行レベルのアクセス ポリシーを表示するには、Google Cloud コンソールの [BigQuery] ページに移動します。

   [BigQuery] に移動

2. テーブル名をクリックして詳細を表示し、[行アクセス ポリシーを表示] をクリックします。

   

3. [行アクセス ポリシー] パネルを開くと、テーブルのすべての行レベルのアクセス ポリシーのリストが名前順に表示されます。また、各ポリシーの filter_expression も表示されます。

   

4. 行レベルのアクセス ポリシーの影響を受けるすべてのロールとユーザーを表示するには、ポリシーの横にある [表示] をクリックします。たとえば、次の図では、[権限の表示] パネルで、譲受人リストのメンバーに bigquery.filteredDataViewer ロールが付与されていることを確認できます。

   

   重要: 現在、ポリシーへのメンバーの追加とポリシーからのメンバーの削除は、DDL ステートメントの使用のみがサポートされています。

bq

bq ls コマンドを入力して、--row_access_policies フラグを指定します。データセット名とテーブル名は必須です。

    bq ls --row_access_policies dataset.table

たとえば、次のコマンドは、ID が my_dataset のデータセット内の my_table というテーブルにある行レベルのアクセス ポリシーに関する情報を一覧表示します。

    bq ls --row_access_policies my_dataset.my_table

API

REST API リファレンス セクションの RowAccessPolicies.List メソッドを使用します。

行レベルのアクセス ポリシーを削除する

権限があれば、DDL ステートメントを使用して、テーブルの 1 つまたはすべての行レベルのアクセス ポリシーを削除できます。

必要な権限

行レベルのアクセス ポリシーを削除するには、次の IAM 権限が必要です。

• bigquery.rowAccessPolicies.delete
• bigquery.rowAccessPolicies.setIamPolicy
• bigquery.jobs.create（DDL クエリジョブを実行するためのもの）

テーブルのすべての行レベルのアクセス ポリシーを同時に削除するには、次の IAM 権限が必要です。

• bigquery.rowAccessPolicies.delete
• bigquery.rowAccessPolicies.setIamPolicy
• bigquery.rowAccessPolicies.list
• bigquery.jobs.create（DDL クエリジョブを実行するためのもの）

事前定義された次の IAM ロールには、行レベルのアクセス ポリシーを削除するために必要な権限が含まれています。

• roles/bigquery.admin
• roles/bigquery.dataOwner

BigQuery での IAM のロールと権限について詳しくは、事前定義ロールと権限をご覧ください。

行レベルのアクセス ポリシーを削除する

テーブルから行アクセス ポリシーを削除するには、次の DDL ステートメントを使用します。

• DROP ROW ACCESS POLICY ステートメントは、指定されたテーブルの行レベルのアクセス ポリシーを削除します。

• DROP ROW ACCESS POLICY IF EXISTS ステートメントは、指定されたテーブルに行アクセス ポリシーが存在する場合、行レベルのアクセス ポリシーを削除します。

• DROP ALL ROW ACCESS POLICIES ステートメントは、指定されたテーブルのすべての行レベルのアクセス ポリシーを削除します。

重要: DROP ROW ACCESS POLICY を使用して、テーブルから最後の行レベルのアクセス ポリシーを削除することはできません。このような操作を行うと、エラーになります。テーブルの最後の行レベルのアクセス ポリシーを削除するには、代わりに DROP ALL ROW ACCESS POLICIES を使用する必要があります。最後の行レベルのアクセス ポリシーをテーブルから削除する方法については、行レベルのセキュリティのベスト プラクティスをご覧ください。

例

テーブルから行レベルのアクセス ポリシーを削除します。

DROP ROW ACCESS POLICY my_row_filter ON project.dataset.my_table;

テーブルからすべての行レベルのアクセス ポリシーを削除します。

DROP ALL ROW ACCESS POLICIES ON project.dataset.my_table;

行レベルのアクセス ポリシーの削除の詳細については、DROP ROW ACCESS POLICY DDL ステートメント リファレンスをご覧ください。

行レベルのアクセス ポリシーを使用してテーブルにクエリを実行する

BigQuery テーブルに対する行アクセス ポリシーの grantee_list に含まれている場合でも、そのテーブルにクエリを実行するには、テーブルに対するアクセス権が必要です。権限がない状態でクエリを実行すると、access denied エラーが発生します。

必要な権限

行レベルのアクセス ポリシーを使用して BigQuery テーブルに対してクエリを実行するには、bigquery.tables.getData IAM 権限と bigquery.rowAccessPolicies.getFilteredData IAM 権限が必要です。関連するすべてのテーブルに対して bigquery.tables.getData IAM 権限が必要です。

これらのロールを事前定義ロールで取得するには、roles/bigquery.dataViewer と roles/bigquery.filteredDataViewer の IAM ロールが付与されている必要があります。

列レベルのセキュリティを使用するには、関連するすべての列に対して datacatalog.categories.fineGrainedGet 権限が必要です。この権限を事前定義ロールで取得するには、datacatalog.categoryFineGrainedReader ロールが必要です。

クエリ結果を表示する

Google Cloud コンソールで、行レベルのアクセス ポリシーを使用してテーブルにクエリを実行すると、結果が行レベルのアクセス ポリシーでフィルタリングされた可能性があることを示すバナー通知が表示されます。この通知は、ポリシーの付与対象リストのメンバーにも表示されます。

ジョブ統計

Job API を使用して行レベルのアクセス ポリシーが適用されたテーブルに対してクエリを実行すると、BigQuery は、Job レスポンス オブジェクト内の行アクセス ポリシーが適用されたテーブルをクエリで読み取るかどうかを示します。

例

この Job オブジェクトのレスポンスでは、わかりやすくするために一部の値を省略しています。

{
  "configuration": {
    "jobType": "QUERY",
    "query": {
      "priority": "INTERACTIVE",
      "query": "SELECT * FROM dataset.table",
      "useLegacySql": false
    }
  },
  ...
  "statistics": {
    ...
    rowLevelSecurityStatistics: {
      rowLevelSecurityApplied: true
    },
    ...
  },
  "status": {
    "state": "DONE"
  },
  ...
}

次のステップ

• 行レベルのセキュリティが他の BigQuery の機能やサービスとどのように連携するかについては、他の BigQuery の機能とともに行レベルのセキュリティを使用するをご覧ください。

• 行レベルのセキュリティに関するベスト プラクティスについては、BigQuery での行レベルのセキュリティのベスト プラクティスをご覧ください。