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

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

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

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

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

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

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

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

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

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', 'alice@examplecustomers.com', 'Japan', 'APAC'),
  ('Example Enterprise Group', 'bob@exampleenterprisegroup.com', 'Singapore', 'APAC'),
  ('Example HighTouch Co.', 'carrie@examplehightouch.com', 'USA', 'US'),
  ('Example Buyers Inc.', 'david@examplebuyersinc.com', 'USA', 'US');

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

CREATE ROW ACCESS POLICY
  apac_filter
ON
  dataset1.table1 GRANT TO ("group: sales-apac@example.com")
FILTER USING
  (region="APAC" );

その結果、グループ sales-apac@example.com のユーザーは、region の値が APAC の行のみを表示できます。

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

CREATE ROW ACCESS POLICY
  us_filter
ON
  dataset1.table1 GRANT TO ("group:sales-us@example.com",
"user: jon@example.com")
FILTER USING
  (region="US");

その結果、グループ sales-us@example.com のユーザーとユーザー jon@example.com は、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, 'jim@example.com'),
  ('Anna K', 'Finance', 100000, 'anna@example.com'),
  ('Bruce L', 'Engineering', 100000, 'bruce@example.com'),
  ('Carrie F', 'Business', 100000, 'carrie@example.com');

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

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

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

給与の行レベルのセキュリティに関するユースケース

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

この機能に関するフィードバックやサポートのリクエストを行う場合は、bigquery-row-level-security-support@google.com 宛てにメールでお送りください。

サブクエリをサポートすることで、行アクセスポリシーで他のテーブルを参照し、ルックアップテーブルとして使用できます。フィルタリングルールで使用されるデータはテーブルに格納できます。また、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 での行レベルのセキュリティのベストプラクティスをご覧ください。