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 の行レベルのセキュリティに関するベスト プラクティスをご覧ください。

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

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

セキュリティ 最適な用途
承認済み
ビュー
慎重に作成されたクエリ、クエリの実行時間、その他の種類のサイドチャネル攻撃に対して脆弱です。 柔軟性とパフォーマンスが特に重要な場合。

例: 同じ作業グループ内でデータを共有する場合。
行レベルのアクセス ポリシー 慎重に作成されたクエリとクエリの実行時間のサイドチャネル攻撃に対して脆弱です。 すべてのユーザーが同じテーブルに対してクエリを実行できることが便利な場合。たとえば、全員が同じダッシュボードを共有しているものの、一部のユーザーはさらに多くのデータにアクセスできる場合です。

ビューのセキュリティを強化する場合。

例: 組織内のテーブル スライスの共有。
個別のテーブル 完全な分離。 分離が非常に重要な場合。たとえば、行の合計数が秘密であることが必要な場合。

例: サードパーティのパートナーやベンダーなどと組織外のデータを共有する場合。

行レベルのアクセス ポリシーの作成と管理

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

割り当て

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

料金

行レベルのセキュリティは、BigQuery に無料で含まれています。

テーブルの行レベルのアクセス ポリシーにアクセスした際の請求額は、クエリの場合と同様です。ただし、行レベルのアクセス ポリシーは、処理されるバイト数に次のようにして間接的に影響を与える可能性があります。

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

制限事項

行レベルのセキュリティには、次の制限事項があります。

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

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

セキュリティの制限

収益情報を含むテーブルがあるとします。この機密データは、行レベルのアクセス ポリシーで保護され、ビジネス ユニットに基づいて行がフィルタされます。このテーブルにアクセスできるユーザーが、保護された行に対して直接クエリを実行できないようにするセキュリティ フィルタ述語が用意されているとしても、ユーザーは、慎重に作成したクエリを繰り返し、クエリのエラー メッセージをモニタリングすることによって、他のビジネス ユニットの収益情報を取得できる可能性があります。

  • 具体的には、基になるテーブルにアクセスできる悪意のあるユーザーが、クエリでゼロ除算の例外が返されると、保護された行の値を取得する可能性があります。
  • ゼロ除算の例外は、SELECT * FROM dataset.table WHERE 1/(100000-revenue) = 1 のようなクエリから生成されます。その結果、悪意のあるユーザーが、テーブル内に存在している収益が $100,000 であることを学習できてしまう可能性があります。
  • 多くの場合、この種の攻撃では、行レベルのセキュリティが適用されたテーブルに対して大量の再試行が必要になります。管理者が行レベルのセキュリティが適用されたテーブルでの不審なアクティビティを確認するために Cloud Audit Logs をモニタリングすることをおすすめします。

サイドチャネル攻撃を制限する方法の詳細については、BigQuery での行レベルのセキュリティに関するベスト プラクティスをご覧ください。

その他の制限

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

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

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

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

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

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

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

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

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

次のステップ