このページは Cloud Translation API によって翻訳されました。

他の BigQuery 機能での行レベルのセキュリティの使用

このドキュメントでは、他の BigQuery 機能で行レベルのアクセスセキュリティを使用する方法について説明します。

このドキュメントを読む前に、BigQuery の行レベルのセキュリティの概要および行レベルのセキュリティの操作をお読みになり、行レベルのセキュリティを理解してください。

`TRUE` フィルタ

行レベルのアクセスポリシーを使用すると、クエリの実行時にユーザーに表示される結果データをフィルタできます。DML などのクエリ以外のオペレーションを実行するには、テーブル内のすべての行に対する完全アクセス権が必要です。完全アクセス権は、フィルタ式を TRUE に設定した行アクセスポリシーを使用することで付与されます。この行レベルのアクセスポリシーは TRUE フィルタと呼ばれます。

TRUE フィルタのアクセス権は、どのユーザー（サービスアカウントを含む）にも付与できます。

クエリ以外のオペレーションの例を次に示します。

その他の BigQuery API（BigQuery Storage Read API など）。
bq head コマンドなど、一部の bq コマンドラインツールコマンド。
テーブルのコピー

例

`TRUE` フィルタを作成する

CREATE ROW ACCESS POLICY all_access ON project.dataset.table1
GRANT TO ("group:all-rows-access@example.com")
FILTER USING (TRUE);

`TRUE` フィルタと連携する機能

コピージョブ

1 つ以上の行レベルのアクセスポリシーを使用してテーブルをコピーするには、まず、ソーステーブルに対する TRUE フィルタへのアクセス権が付与されている必要があります。ソーステーブルに対するすべての行レベルのアクセスポリシーも、新しい宛先テーブルにコピーされます。行レベルのアクセスポリシーのないソーステーブルを、行レベルのアクセスポリシーがある宛先テーブルにコピーすると、行レベルのアクセスポリシーは宛先テーブルから削除されます（--append_table フラグが使用されている場合や、"writeDisposition": "WRITE_APPEND" が設定されている場合を除く）。

リージョン間のコピーは許可され、すべてのポリシーがコピーされます。サブクエリポリシーで無効なテーブル参照がクエリに含まれている場合、コピーが完了した後に後続のクエリが機能しない可能性があります。

テーブルの行レベルのアクセスポリシーには一意の名前を付ける必要があります。コピー中に行レベルのアクセスポリシー名が競合すると入力エラーが発生します。

行レベルのアクセスポリシーが適用されたテーブルをコピーするために必要な権限

1 つ以上の行レベルのアクセスポリシーが適用されたテーブルをコピーするには、テーブルとパーティションをコピーするロールに加えて、次の権限が必要です。

権限	リソース
`bigquery.rowAccessPolicies.list`	ソーステーブル。
`bigquery.rowAccessPolicies.getIamPolicy`	ソーステーブル。
`TRUE` フィルタ。	ソーステーブル。
`bigquery.rowAccessPolicies.create`	宛先テーブル。
`bigquery.rowAccessPolicies.setIamPolicy`	宛先テーブル。

BigQuery API の tabledata.list

行レベルのアクセスポリシーが適用されたテーブルに対して BigQuery API の tabledata.list メソッドを使用するには、TRUE フィルタのアクセス権が必要です。

DML

行レベルのアクセスポリシーを持つテーブルを更新する DML ステートメントを実行するには、テーブルに対する TRUE フィルタのアクセス権が必要です。

特に、MERGE ステートメントは、行レベルのアクセスポリシーと次のように相互作用します。

ターゲットテーブルに行レベルのアクセスポリシーが含まれている場合は、ターゲットテーブルに対する TRUE フィルタのアクセス権が必要です。
ソーステーブルに行レベルのアクセスポリシーが含まれている場合、MERGE ステートメントはユーザーに表示される行でのみ機能します。

テーブルスナップショット

テーブルスナップショットは、行レベルのセキュリティをサポートします。ベーステーブル（ソーステーブル）とテーブルスナップショット（宛先テーブル）に必要な権限については、行レベルのアクセスポリシーが適用されたテーブルをコピーするために必要な権限で説明しています。

JSON 列を含む BigQuery テーブル

行レベルのアクセスポリシーを JSON 列に適用することはできません。行レベルのセキュリティに関する制限事項の詳細については、制限事項をご覧ください。

BigQuery BI Engine と Looker Studio

BigQuery BI Engine では、1 つ以上の行レベルのアクセスポリシーを持つテーブルで実行されるクエリは高速化されません。そうしたクエリは、BigQuery で標準クエリとして実行されます。

Looker Studio ダッシュボードのデータは、元になるソーステーブルの行レベルのアクセスポリシーに従ってフィルタされます。

列レベルのセキュリティ

行レベルのセキュリティと列レベルのセキュリティには、列レベルのアクセス制御と動的データマスキングの両方が含まれており、完全な互換性があります。

要点は次のとおりです。

行レベルのアクセスポリシーは、その列内のデータに対するアクセス権がない場合でも、任意の列のデータをフィルタリングするように適用できます。
- サブクエリの行レベルのアクセスポリシーを使用してこれらの列にアクセスしようとすると、アクセスが拒否されたことを示すエラーが発生します。これらの列は、システム参照列とは見なされません。
- サブクエリ以外の行レベルのアクセスポリシーを使用してこれらの列にアクセスしようとすると、列レベルのセキュリティがバイパスされます。
列レベルのセキュリティが原因で列が制限される場合、クエリの SELECT ステートメントまたはサブクエリの行レベルのアクセスポリシーで列の名前を指定すると、エラーが発生します。
列レベルのセキュリティは、SELECT * クエリステートメントにも適用されます。SELECT * は、制限付きの列を明示的に指定するクエリと同じように処理されます。

行レベルのセキュリティと列レベルのセキュリティの操作の例

この例では、テーブルを保護してそのテーブルにクエリを行う手順について説明します。

データ

my_dataset という名前のデータセットに対する DataOwner ロールを付与されており、このロールに my_table という名前の 3 つの列が配置されたテーブルが含まれているとします。テーブルには、次の表に示すデータが含まれています。

この例で、ユーザーの 1 人は Alice、メールアドレスは alice@example.com です。2 人目のユーザーは、Alice の同僚の Bob です。

ランク	果物	色
1	リンゴ	赤
2	オレンジ	オレンジ
3	レモン	黄
4	ライム	green

セキュリティ

Alice が rank 列に奇数が入力されたすべての行を表示でき、偶数が入力された行は無視できるようにします。Bob には行を（偶数か奇数かにかかわらず）表示しないようにします。fruit 列のデータは誰にも表示しないようにします。

Alice が偶数が入力された行を表示できないように制限するには、rank 列に表示されるデータに基づくフィルタ式を含む行レベルのアクセスポリシーを作成します。Bob が偶数が入力された行または奇数が入力された行を表示できないようにするには、Bob を譲受人リストに含めないでください。
```
CREATE ROW ACCESS POLICY only_odd ON my_dataset.my_table GRANT
TO ('user:alice@example.com') FILTER USING (MOD(rank, 2) = 1);
```
すべてのユーザーが fruit という名前の列のデータを表示できないようにするには、すべてのユーザーにデータへのアクセスを禁止する列レベルのセキュリティポリシータグを作成します。

最後に、次の 2 つの方法で color という名前の列へのアクセスを制限することもできます。列は全員のすべてのアクセスを禁止する列レベルのセキュリティポリシータグによって管理され、color 列内の行データの一部をフィルタする行レベルのアクセスポリシーの影響を受けます。

この 2 番目の行レベルのアクセスポリシーでは、color 列の値が green の行のみ表示されます。

CREATE ROW ACCESS POLICY only_green ON my_dataset.my_table
GRANT TO ('user:alice@example.com') FILTER USING (color="green");

Bob のクエリ

Alice の同僚である Bob が my_dataset.my_table からデータをクエリしようとしても、Bob はテーブルの行レベルのアクセスポリシーに対する譲受人リストに含まれていないため、行が表示されません。

クエリ	`my_dataset.my_table`			コメント
	`rank` （一部のデータは行アクセスポリシー `only_odd` の影響を受けます）	`fruit` （すべてのデータが CLS ポリシータグで保護されます）	`color` （すべてのデータが CLS ポリシータグで保護され、一部のデータは行アクセスポリシー `only_green` の影響を受けます）
`SELECT rank FROM my_dataset.my_table`	（0）行が返されます。			Bob は、行レベルのアクセスポリシーの譲受人リストではないため、このクエリは成功しますが、行データは返されません。行アクセスポリシーによって結果をフィルタできることを示すメッセージが Bob に表示されます。

Alice のクエリ

Alice が my_dataset.my_table のデータにアクセスするためのクエリを実行する場合、その結果は、次の表に示すように、実行するクエリとセキュリティによって異なります。

クエリ	`my_dataset.my_table`			コメント
	`rank` （一部のデータは行アクセスポリシー `only_odd` の影響を受けます）	`fruit` （すべてのデータが CLS ポリシータグで保護されます）	`color` （すべてのデータが CLS ポリシータグで保護され、一部のデータは行アクセスポリシー `only_green` の影響を受けます）
`SELECT rank FROM my_dataset.my_table`	（2）奇数が入力された行が返されます。			Alice は、ランク列のデータに対する `only_odd` 行レベルのアクセスポリシーの譲受人リストに含まれています。したがって、Alice には奇数行のデータのみが表示されます。偶数行は、`only_odd` という名前の行レベルのアクセスポリシーによって非表示になります。行アクセスポリシーによって結果をフィルタできることを示すメッセージが Alice に表示されます。
`SELECT fruit FROM my_dataset.my_table`		`access denied`		クエリ内で `fruit` 列が明示的に指定されています。列レベルのセキュリティが適用されます。アクセスが拒否されます。
`SELECT color FROM my_dataset.my_table`			`access denied`	クエリ内で `color` 列が明示的に指定されています。 `color` 列のデータに対する行レベルのアクセスポリシーが適用される前に、列レベルのセキュリティが適用されます。アクセスが拒否されます。
`SELECT rank, fruit FROM my_dataset.my_table`		`access denied`		クエリ内で `fruit` 列が明示的に指定されています。 `rank` 列のデータに対する行レベルのアクセスポリシーが適用される前に、列レベルのセキュリティが適用されます。アクセスが拒否されます。
`SELECT rank, color FROM my_dataset.my_table`			`access denied`	クエリで `color` 列が明示的に指定されています `color` に対する列レベルのセキュリティは、`rank` 列と `color` 列のデータに対する行レベルのアクセスポリシー適用される前に適用されます。アクセスが拒否されます。
`SELECT fruit, color FROM my_dataset.my_table`		`access denied`	`access denied`	クエリで `fruit` 列と `color` 列が明示的に指定されています。 `fruit` 列と `color` 列に対する列レベルのセキュリティは、`color` 列のデータに対して行レベルのアクセスポリシーが適用される前に適用されます。アクセスが拒否されます。
`SELECT * FROM my_dataset.my_table`		`access denied`	`access denied`	`fruit` 列と `color` 列には、クエリで「`SELECT *`」を使用することによって暗黙的に名前が付けられています。 `fruit` 列と `color` 列に対する列レベルのセキュリティは、`rank` 列または `color` のデータに対して行レベルのアクセスポリシーが適用される前に適用されます。アクセスが拒否されます。

`TRUE` フィルタのアクセス権

最後に、TRUE のフィルタのアクセス権についてのセクションで説明したように、Alice や Bob に TRUE フィルタのアクセス権が付与されている場合は、テーブルの行すべてを確認し、クエリ以外のジョブで使用できます。ただし、テーブルに列レベルのセキュリティがあると、それが適用され、結果に影響を与える可能性があります。

実行グラフ

行レベルのアクセスポリシーが適用されたジョブには、クエリ実行グラフを使用できません。

ジョブを抽出する

テーブルに行レベルのアクセスポリシーがある場合、抽出ジョブを実行すると、表示できるデータのみが Cloud Storage にエクスポートされます。

レガシー SQL

行レベルのアクセスポリシーにはレガシー SQL との互換性がありません。行レベルのアクセスポリシーが適用されたテーブルのクエリでは、GoogleSQL を使用する必要があります。レガシー SQL クエリは拒否されます。

パーティション分割テーブルとクラスタ化テーブル

行レベルのセキュリティは、パーティション分割テーブルの機能であるクエリのプルーニングには関与しません。

行レベルのセキュリティはパーティション分割テーブルやクラスタ化されたテーブルと互換性がありますが、行データをフィルタする行レベルのアクセスポリシーは、パーティションのプルーニング中は適用されません。パーティション列で実行される WHERE 句を指定することで、行レベルのセキュリティを使用するテーブルでもパーティションのプルーニングを使用できます。同様に、行レベルのアクセスポリシー自体は、クラスタ化テーブルに対するクエリのパフォーマンス上のメリットをもたらしませんが、適用する他のフィルタの妨げになることはありません。

クエリのプルーニングは、ポリシーでフィルタを使用して行レベルのアクセスポリシーを実行する際に行われます。

テーブルの名前を変更する

複数の行アクセスポリシーを含むテーブルの名前を変更する場合、TRUE フィルタのアクセス権は必要ありません。テーブル名は DDL ステートメントで変更できます。

別の方法として、テーブルをコピーし宛先テーブルに異なる名前を付けることもできます。ソーステーブルに行レベルのアクセスポリシーが存在する場合の詳細については、このページのテーブルコピージョブをご覧ください。

ストリーミング更新

変更データキャプチャを使用してストリーミングテーブルの UPDATE または DELETE オペレーションを実行するには、TRUE フィルタのアクセス権が必要です。

タイムトラベル

行レベルのアクセスポリシーがある、または以前に存在していたテーブルの過去のデータにアクセスできるのは、テーブル管理者のみです。他のユーザーが行レベルのアクセスポリシーがあるテーブルでタイムトラベルデコレータを使用すると、access denied エラーが発生します。詳細については、タイムトラベルと行レベルのアクセスをご覧ください。

ビューとマテリアライズドビュー

ビューまたはマテリアライズドビューに表示されるデータは、基になるソーステーブルの行レベルのアクセスポリシーに従ってフィルタリングされます。

さらに、マテリアライズドビューが、行レベルのアクセスポリシーを持つ基になるテーブルから派生している場合、クエリのパフォーマンスはソーステーブルを直接クエリする場合と同じです。つまり、ソーステーブルに行レベルのセキュリティが適用された場合、ソーステーブルに対するクエリと比較して、マテリアライズドビューに対するクエリとソーステーブルのクエリの一般的なパフォーマンス上のメリットはありません。

行レベルのアクセスポリシーでビューまたはマテリアライズドビューを参照することはできません。

ワイルドカードクエリ

行レベルのアクセスポリシーが適用されたテーブルに対するワイルドカードクエリは、INVALID_INPUT エラーで失敗します。

次のステップ

行レベルのアクセスポリシーのベストプラクティスについて、BigQuery での行レベルのセキュリティに関するベストプラクティスで確認する。