BigQuery の行レベルのセキュリティの概要

注: 特定の BigQuery エディションで作成された予約を使用する場合、この機能は使用できません。各エディションで有効になる機能の詳細については、BigQuery エディションの概要をご覧ください。

このドキュメントでは、行レベルのセキュリティのコンセプト、BigQuery での動作、行レベルのセキュリティを使用してデータを保護するタイミングなどの詳細について説明します。

行レベルのセキュリティとは

行レベルのセキュリティを使用すると、データをフィルタし、ユーザーの資格条件に基づいてテーブル内の特定の行へのアクセスを許可できます。

BigQuery では、プロジェクト レベル、データセット レベル、テーブルレベルでのアクセス制御と、ポリシータグによる列レベルのセキュリティがサポートされています。行レベルのセキュリティでは、行レベルのアクセス ポリシーを使用して BigQuery テーブル内のデータのサブセットに対するきめ細かいアクセス制御を可能にすることで、最小権限の原則を拡張します。

1 つのテーブルには、行レベルのアクセス ポリシーを複数設定できます。行レベルのアクセス ポリシーによって、 列レベルのセキュリティと、データセット レベル、テーブルレベル、プロジェクト レベルのアクセス制御が 1 つのテーブルに共存できます。

行レベルのセキュリティの仕組み

大まかに言うと、行レベルのセキュリティでは、ターゲット BigQuery テーブルに行レベルのアクセス ポリシーを作成する必要があります。これらのポリシーは、ユーザーまたはグループが許可リストに含まれているかどうかに応じて、特定のデータ行を表示または非表示にするフィルタとして機能します。許可リストに明確に含まれていないユーザーまたはグループは、アクセスを拒否されます。

注: 行アクセスを制限する新しい行レベルのセキュリティ ポリシーを作成する場合は、以前に完全アクセス権を持っていたユーザーを TRUE フィルタに追加して、そのアクセスを維持する必要があります。

Identity and Access Management（IAM）のロール（BigQuery 管理者または BigQuery DataOwner）を持つ承認されたユーザーは、BigQuery テーブルに対する行レベルのアクセス ポリシーを作成できます。

行レベルのアクセス ポリシーを作成する場合は、テーブルを名前で指定し、加えて特定の行データにアクセスできるユーザーまたはグループ（grantee-list）を指定します。ポリシーには、フィルタに使用するデータ（filter_expression）も含まれています。filter_expression は、一般的なクエリでの WHERE 句のように機能します。

注: WHERE 句と同様、filter_expression は、grantee_list のプリンシパルに表示するデータと一致します。grantee_list に入っていないユーザーは、行を表示できません。

行レベルのアクセス ポリシーを作成して使用する方法については、行レベルのセキュリティの使用をご覧ください。

行レベルのアクセス ポリシーの作成時の完全な構文、使用方法、オプションに関する DDL リファレンスをご覧ください。

サンプル ユースケース

次の例は、行レベルのセキュリティのユースケースを示しています。

リージョンに基づく行データをフィルタする

テーブル dataset1.table1 に、（region 列によって示される）さまざまなリージョンに属している行が含まれているとします。

次のクエリを使用して、サンプル テーブルを作成してデータを入力できます。

CREATE TABLE IF NOT EXISTS
  dataset1.table1 (partner STRING,
    contact STRING,
    country STRING,
    region STRING);
INSERT INTO
  dataset1.table1 (partner,
    contact,
    country,
    region)
VALUES
  ('Example Customers Corp', '[e-mail]', 'Japan', 'APAC'),
  ('Example Enterprise Group', '[e-mail]', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', '[e-mail]', 'USA', 'US'),
  ('Example Buyers Inc.', '[e-mail]', 'USA', 'US');

行レベルのセキュリティにより、データオーナーまたは管理者はポリシーを実装できます。次のステートメントは、APAC メーリング グループ内のユーザーが APAC リージョンのパートナーのみを表示できるように制限するポリシーを実装します。

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group: [e-mail]")
FILTER USING
  (region="APAC" );

その結果、グループ [e-mail] のユーザーは、region の値が APAC の行のみを表示できます。

次のステートメントは、個人とグループの両方が米国リージョンのパートナーのみを表示するように制限するポリシーを実装します。

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:[e-mail]",
"user: [e-mail]")
FILTER USING
  (region="US");

その結果、グループ [e-mail] のユーザーとユーザー [e-mail] は、region の値が US である行のみを表示できます。

次の図は、前の 2 つのアクセス ポリシーが、テーブル内のどの行をどのユーザーとグループが表示できるかを制限する方法を示しています。

APAC グループまたは US グループに含まれないユーザーに対しては行が表示されません。

機密データに基づいて行データをフィルタする

ここで、給与情報が含まれているテーブルがある別のユースケースについて考えてみましょう。

次のクエリを使用して、サンプル テーブルを作成してデータを入力できます。

CREATE OR REPLACE TABLE
  dataset1.table1 (name STRING,
    department STRING,
    salary INT64,
    email STRING);
INSERT INTO
  dataset1.table1 ( name,
    department,
    salary,
    email)
VALUES
  ('Jim D', 'HR', 100000, '[e-mail]'),
  ('Anna K', 'Finance', 100000, '[e-mail]'),
  ('Bruce L', 'Engineering', 100000, '[e-mail]'),
  ('Carrie F', 'Business', 100000, '[e-mail]');

次のステートメントの行アクセス ポリシーは、クエリ対象を会社ドメインのメンバーに制限します。さらに、SESSION_USER() 関数を使用すると、ユーザーのメールアドレスに基づいて、クエリを実行するユーザーに属する行のみにアクセス先を詳細に制限できます。

CREATE ROW ACCESS POLICY
  salary_personal
ON
  dataset1.table1 GRANT TO ("domain:example.com")
  FILTER USING
  (Email=SESSION_USER());

次の図は、行アクセス ポリシーが給与情報を含むテーブルを制限する方法を示しています。この例では、ユーザー名は Jim、メールアドレスは [e-mail] です。

注: 行レベルのセキュリティのその他の例については、行レベルのセキュリティを使用するをご覧ください。

ルックアップ テーブルに基づいて行データをフィルタする

プレビュー

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

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

サブクエリをサポートすることで、行アクセス ポリシーで他のテーブルを参照し、ルックアップ テーブルとして使用できます。フィルタリング ルールで使用されるデータはテーブルに格納できます。また、1 つのサブクエリ行アクセス ポリシーで、複数の構成済み行アクセス ポリシーを置き換えることができます。行アクセス ポリシーを更新するには、ルックアップ テーブルを更新するだけで済みます。これにより、複数の行アクセス ポリシーが置き換えられます。個々の行アクセス ポリシーを更新する必要はありません。

行レベルのセキュリティと他のメソッドを使用するタイミング

承認済みビュー、行レベルのアクセス ポリシー、データを個別のテーブルに保存することにより、セキュリティ、パフォーマンス、利便性のさまざまなレベルが実現します。ユースケースに適したメカニズムを選択することは、データのセキュリティの適切なレベルを確保するために重要です。

承認済みビューとの比較（脆弱性）

行レベルのセキュリティと承認済みビューを使用して行レベルのアクセスを適用するのどちらにおいても、適切に使用されないと脆弱性が生じる可能性があります。

行レベルのセキュリティのために承認済みビューまたは行レベルのアクセス ポリシーを使用する場合は、監査ロギングを使用して不審なアクティビティをモニタリングすることをおすすめします。

クエリ期間などのサイドチャネルでは、ストレージ シャードのエッジにある行に関する情報が漏洩する可能性があります。このような攻撃では、テーブルのシャーディングや多数のクエリに関する知識が必要になる場合があります。

このようなサイドチャネル攻撃の防止の詳細については、行レベルのセキュリティに関するベスト プラクティスをご覧ください。

承認済みビュー、行レベルのセキュリティ、個別のテーブルの比較

次の表は、承認済みビュー、行レベルのアクセス ポリシー、個別のテーブルの柔軟性、パフォーマンス、セキュリティを比較したものです。

メソッド	セキュリティ上の考慮事項	推奨事項
承認済み ビュー	柔軟性のためにおすすめします。慎重に作成されたクエリ、クエリの所要時間、その他の種類のサイドチャネル攻撃に対して脆弱である可能性があります。	承認済みビューは、他のユーザーとデータを共有する必要があり、柔軟性とパフォーマンスが重要な場合に適しています。たとえば、承認済みビューを使用して、ワークグループ内でデータを共有できます。
行レベルのアクセス ポリシー	柔軟性とセキュリティのバランスが取れているためにおすすめです。クエリの実行時間のサイドチャネル攻撃に対して脆弱になる可能性があります。	行レベルのアクセス ポリシーは、他のユーザーとデータを共有する必要があり、ビューやテーブル スライスのセキュリティを強化する場合に適しています。たとえば、行レベルのアクセス ポリシーを使用すると、一部のユーザーが他のユーザーよりも多くのデータにアクセスできる場合でも、全員が同じダッシュボードを使用するユーザーとデータを共有できます。
個別のテーブル	セキュリティのためにおすすめします。ユーザーはテーブルへのアクセス権なしではデータを推測できません。	他のユーザーとデータを共有し、データの分離を維持する必要がある場合には、個別のテーブルが適しています。たとえば、行の合計数が秘密にする必要がある場合、個別のテーブルを使用してサードパーティのパートナーやベンダーとデータを共有できます。

行レベルのアクセス ポリシーを作成および管理する

テーブルの行レベルのアクセス ポリシーの作成、更新（再作成）、一覧表示、表示、削除の方法と、行レベルのアクセス ポリシーを使用してテーブルに対してクエリを実行する方法の詳細については、行レベルのアクセス セキュリティの操作をご覧ください。

割り当て

行レベルのセキュリティの割り当てと上限の詳細については、BigQuery の割り当てと上限をご覧ください。

料金

行レベルのセキュリティは、BigQuery に追加料金なしで含まれています。ただし、行レベルのアクセス ポリシーは、次のようにクエリの実行費用に影響を与える可能性があります。

• 行レベルのアクセス ポリシー（特に他のテーブルを参照するサブクエリを含むポリシー）が原因で、追加の課金が発生することがあります。

• 行レベルのアクセス ポリシーのフィルタは、パーティション分割テーブルとクラスタ化テーブルのクエリ プルーニングに使用されません。これは、メインクエリの実行中に読み取るデータが増えるという意味ではありません。今後のプルーニングに行アクセス ポリシーの述語は利用されないということです。

• 行レベルのアクセス ポリシー フィルタでは、すべてのユーザー フィルタが早期に適用されるわけではありません。このため、テーブルから読み取られるデータが増え、より多くの行が読み取られ、課金される可能性があります。

BigQuery クエリの料金の詳細については、BigQuery の料金をご覧ください。

制限事項

行レベルのセキュリティの上限については、BigQuery の行レベルのセキュリティの上限をご覧ください。以降のセクションでは、その他の行レベルのセキュリティに関する制限事項について説明します。

パフォーマンスの制限事項

• BigQuery の一部の機能は、BigQuery BI Engine やマテリアライズド ビューなどの行レベルのアクセス ポリシーを含むテーブルを操作する際に加速されません。

• 行レベルのセキュリティは、パーティション分割テーブルの機能であるクエリのプルーニングには関与しません。詳細については、パーティション分割テーブルとクラスタ化テーブルをご覧ください。この制限は、メインクエリの実行速度を低下させるものではありません。

• 行レベルのセキュリティが設定されているテーブルをクエリすると、パフォーマンスがわずかに低下する可能性があります。

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

その他の制限

• 特定の BigQuery エディションで作成された予約を使用する場合、この機能は使用できません。各エディションで有効になる機能の詳細については、BigQuery エディションの概要をご覧ください。

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

• 行レベルのアクセス ポリシーを JSON 列に適用することはできません。

• BigQuery の一部の機能は、行レベルのセキュリティに対応していません。詳細については、行レベルのセキュリティの使用をご覧ください。

• テーブルデータへの完全アクセス権が必要なクエリ以外のオペレーション（サービス アカウント ジョブを含む）では、TRUE フィルタを使用して行レベルのセキュリティを使用できます。テーブルのコピー、Dataproc ワークフローなどがそれに該当します。詳細については、行レベルのセキュリティの使用をご覧ください。

• 行レベルのアクセス ポリシーの作成、置き換え、削除は、DDL ステートメントを使用して行う必要があります。行レベルのアクセス ポリシーの一覧や内容の表示は、Google Cloud コンソールまたは bq コマンドライン ツールを使用して行うことができます。

• テーブルのプレビューまたは閲覧は、行レベルのセキュリティに対応していません。

• テーブルのサンプリングは、行レベルのセキュリティに対応していません。

• 最上位のサブクエリ ポリシーの結果は 100 MB に制限されています。この上限は行レベルのアクセス ポリシーごとに適用されます。

• 参照先テーブルが削除され、行レベルのアクセス ポリシーの述語を評価できない場合、クエリは失敗します。

• サブクエリの行レベルのアクセス ポリシーがサポートしているのは、BigQuery テーブル、BigLake 外部テーブル、BigLake マネージド テーブルだけです。

監査ロギングとモニタリング

1 つ以上の行レベルのアクセス ポリシーが適用されたテーブルのデータが読み取られると、その読み取りアクセス用に承認された行レベルのアクセス ポリシーと、サブクエリで参照されている対応テーブルが、その読み取りリクエストの IAM 承認情報に表示されます。

行レベルのアクセス ポリシーの作成と削除は監査ログに記録され、Cloud Logging からアクセスできます。監査ログには、行レベルのアクセス ポリシーの名前が含まれます。ただし、行レベルのアクセス ポリシーの filter_expression と grantee_list の定義には、ユーザーや他の機密情報が含まれている可能性があるため、ログから除外されています。行レベルのアクセス ポリシーの一覧と内容の表示は、監査ログに記録されません。

BigQuery のロギングの詳細については、BigQuery Monitoring の概要をご覧ください。

Google Cloud でのロギングの詳細については、Cloud Logging をご覧ください。

次のステップ

• 行レベルのセキュリティの管理については、行レベルのセキュリティを使用するをご覧ください。

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

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