コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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 の機能とともに行レベルのセキュリティを使用するをご覧ください。

セキュリティの制限

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

その他の制限

  • テーブルでは、最大 100 個の行アクセス ポリシーを使用できます。

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

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

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

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

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

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

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

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

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

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

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

次のステップ