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

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

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

TRUE フィルタ

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

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

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

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 ライム

セキュリティ

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 はテーブルの行レベルのアクセス ポリシーに対する譲受人リストに含まれていないため、Bob には 1 行も表示されません。

クエリ 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 エラーで失敗します。

次のステップ