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

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

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

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

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

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

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

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

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

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

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

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

サンプル ユースケース

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

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

行レベルのセキュリティにより、データオーナーまたは管理者は「group:apac 内ユーザーは APAC リージョンのパートナーのみを表示できる」などのポリシーを実装できます。

リージョンの行レベルのセキュリティに関するユースケース

その結果、グループ sales-apac@example.com のユーザーは Region = "APAC" の行のみを表示できます。同様に、グループ sales-us@example.com のユーザーは、US リージョン内の行のみを表示できます。APAC グループまたは US グループに含まれないユーザーに対しては行が表示されません。

us_filter という名前の行レベルのアクセス ポリシーでは、チーフ US セールス担当者 jon@example.com を含む複数のエンティティに対してアクセス権を付与し、その全員が US リージョンに属している行にアクセスできます。

センシティブ データに基づく行データをフィルタリングする

ここで、別のユースケースを考えてみましょう。給与データのテーブルがあるとします。

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

grantee_list は、クエリ対象を会社ドメインのメンバーに制限します。さらに、SESSION_USER() 関数を使用すると、ユーザーのメールアドレスに基づいて、クエリを実行するユーザーに属する行のみにアクセス先を詳細に制限できます。この場合は jim@example.com です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

割り当て

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

料金

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

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

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

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

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

制限事項

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

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

行レベルのセキュリティが一部の 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 をご覧ください。

次のステップ