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

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

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

true フィルタ

行レベルのアクセス ポリシーを使用すると、クエリの実行時にユーザーに表示される結果データをフィルタできます。クエリ以外のオペレーション(DML など)では、TRUE をフィルタとして含む行アクセス ポリシーによってテーブル内のすべての行に対する完全アクセス権を管理者がユーザーに付与しない限り、データ全体に対してアクセスが拒否される可能性があります。これは true フィルタとも呼ばれます。

true フィルタのアクセス権が付与されるユーザーは、サービス アカウントを含む任意の IAM ユーザーにすることができます。

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

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 フィルタを最初に付与する必要があります。ソーステーブルに対するすべての行レベルのアクセス ポリシーも、新しい宛先テーブルにコピーされます。行レベルのアクセス ポリシーがないテーブルをコピーして、行レベルのアクセス ポリシーが適用されたテーブルを上書きする場合、結果はソーステーブルと同様に、行レベルのアクセス ポリシーがないテーブルになります。

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

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

1 つ以上の行レベルのアクセス ポリシーが適用されたテーブルをコピーするには、以下の権限に加えて、行レベルのアクセス ポリシーのないテーブルのコピーに必要な権限が必要になります。

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

Storage Read API、BigQuery API の tabledata.list

行レベルのアクセス ポリシーが適用されたテーブルで Storage API または BigQuery API の tabledata.list メソッドを使用するには、true フィルタがユーザーに付与されている必要があります。

これには、Storage Read API を使用する DataProc のワークロードが含まれます。

DML

行レベルのアクセス ポリシーが適用されたテーブルで DML ステートメントを実行するには、ユーザー(サービス アカウントを含む)に true フィルタを付与する必要があります。

MERGE のターゲット テーブルに行レベルのアクセス ポリシーを格納することはできません。ただし、MERGE ソーステーブルは行レベルのセキュリティと互換性があり、1 つ以上の行レベルのアクセス ポリシーを設定できます。

ソーステーブルに行レベルのアクセス ポリシーが 1 つ以上ある場合、MERGE ステートメントは、それらのアクセス ポリシーに従って、クエリ行を実行するユーザー アカウントに表示される行のみに対して動作します。

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

テーブル スナップショットは、行レベルのセキュリティをサポートします。行レベルのアクセス ポリシーでテーブルをコピーする場合に必要な権限で説明するように、ユーザーは、ベーステーブル(ソーステーブル)とテーブル スナップショット(宛先テーブル)に対して同じ権限を持っている必要があります。行レベルのセキュリティ ポリシーがあるベーステーブルでは、タイムトラベルはサポートされていません。詳しくは、タイムトラベルをご覧ください。

BigQuery BI Engine と Google データポータル

1 つ以上の行レベルのアクセス ポリシーが適用されたテーブルに対するクエリは BigQuery BI Engine によって加速されず、代わりに BigQuery の標準クエリとして実行されます。

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

列レベルのセキュリティ

行レベルのセキュリティと列レベルのセキュリティには完全な互換性があります。

要点は次のとおりです。

  • 行レベルのアクセス ポリシーを適用すると、ユーザーがその列のデータへのアクセス権を持っていない場合でも、任意の列のデータをフィルタリングできます。
  • 列レベルのセキュリティが原因で列が制限される場合に、クエリの SELECT ステートメント内で列の名前を指定すると、アクセス拒否のエラーが発生します。
  • 列レベルのセキュリティは、SELECT * クエリ ステートメントにも適用されます。SELECT * は、制限付きの列を明示的に指定するクエリと同じように処理されます。

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

この詳細な例で、テーブルの保護とクエリの実行について説明します。

データ

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

主なサンプル ユーザーは Alice で、そのメールアドレスは alice@example.com です。セカンダリ ユーザーは 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 はテーブルの行レベルのアクセス ポリシーに対する譲受人リストに含まれていないため、行が表示されません。

クエリ 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 フィルタに関するセクションで説明されているように、管理者または DataOwner が Alice または Bob に true フィルタを付与すると、クエリ以外のジョブで使用するテーブル内のすべての行データを表示できます。ただし、列レベルのセキュリティがテーブルに存在する場合は適用されるため、ジョブの結果に影響を及ぼす可能性があります。

ジョブを抽出する

テーブルに 1 つ以上の行レベルのアクセス ポリシーが存在する場合は、抽出ジョブを使用した Cloud Storage へのテーブルのエクスポートが影響を受けます。行レベルのアクセス ポリシーに従って、現在のユーザーが閲覧できるデータのみが抽出されます。

レガシー SQL

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

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

行レベルのセキュリティは、パーティション分割テーブルの機能であるクエリのプルーニングには関与しません。パーティショニングにより、サイズの大きなテーブルが小さなパーティションに分割され、クエリのパフォーマンスが向上します。したがって、パーティション分割テーブルとクラスタ化テーブルに対するクエリによって読み取られるバイト数を削減することで、コストを制御できます。

テーブルの名前の変更

1 つ以上の行アクセス ポリシーのあるテーブルの名前を変更する場合、true フィルタは必要ありません。テーブル名は DDL ステートメントで変更できます。

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

タイムトラベル

タイムトラベル機能は行レベルのセキュリティをサポートしていません。タイムトラベル デコレータで、1 つ以上の行レベルのアクセス ポリシーのあるテーブルまたは以前に割り当てたテーブルを使用すると、accesss denied エラーが発生します。タイムトラベルを使用してテーブルデータを復旧する必要がある場合は、Cloud カスタマーケアにお問い合わせください。

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

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

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

ワイルドカード クエリ

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

次のステップ