このページの情報の一部またはすべては、S3NS の Trusted Cloud には適用されない場合があります。

他の 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` フィルタと連携する機能

行アクセスポリシーで保護されたテーブルに対して DML オペレーションを使用する場合は、テーブル全体へのアクセスを意味する TRUE フィルタを使用する必要があります。テーブルスキーマを変更しないオペレーションでは、テーブルの行アクセスポリシーが維持されます。

たとえば、ALTER TABLE RENAME TO ステートメントでは、元のテーブルから新しいテーブルに行アクセスポリシーがコピーされます。別の例として、TRUNCATE TABLE ステートメントではテーブルからすべての行が削除されますが、テーブルスキーマと行アクセスポリシーは維持されます。

コピージョブ

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 列に適用することはできません。行レベルのセキュリティに関する制限事項の詳細については、制限事項をご覧ください。

実行グラフ

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

ジョブを抽出する

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

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

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

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

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

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

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

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

ストリーミング更新

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

タイムトラベル

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

論理ビュー、マテリアライズドビュー、承認済みビュー

このセクションでは、さまざまなタイプの BigQuery ビューと、それらのビューが行レベルのセキュリティとどのように連携するかについて説明します。

論理ビューまたはマテリアライズドビュー

論理ビューまたはマテリアライズドビューは、テーブルに対するクエリから構築されます。クエリ結果は通常、テーブルデータのサブセットになります。

どちらのタイプのビューでも、表示されるデータは基になるソーステーブルの行レベルのアクセスポリシーに従ってフィルタされます。ただし、行レベルのアクセスポリシーでビューまたはマテリアライズドビューを参照することはできません。

マテリアライズドビューのパフォーマンス

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

承認済みビュー

論理ビューまたはマテリアライズドビューを承認することもできます。つまり、特定のユーザーまたはグループ（プリンシパル）とビューを共有できます。プリンシパルはビューに対してクエリを実行できますが、基になるテーブルにアクセスすることはできません。詳細については、承認済みビューをご覧ください。

ワイルドカードクエリ

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

次のステップ

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