BigQuery の行レベルのセキュリティに関するベスト プラクティス

このドキュメントでは、行レベルのセキュリティを使用する場合のベスト プラクティスについて説明します。

このドキュメントを読む前に、BigQuery の行レベルのセキュリティの概要および行レベルのセキュリティの操作をお読みになり、行レベルのセキュリティを理解してください。

ユーザー権限を制限してサイドチャネル攻撃を防ぐ

サイドチャネル攻撃は、システムから取得した情報を利用したセキュリティ攻撃です。広範な権限が盗まれると、課金、ロギング、システム メッセージを通じて観察または検索が行われ、機密データが学習される可能性があります。

このような機会を減らすために、BigQuery では、行レベルのセキュリティ、処理されたバイト数、処理されたパーティション数、課金されるバイト数、クエリプランのステージがあるテーブルに対するすべてのクエリで機密統計情報を非表示にします。

センシティブ データへのアクセス権を付与しないように、管理者はフィルタされたデータのみを表示するユーザーに次の権限を付与しないようにすることをおすすめします。

権限 センシティブ データ
プロジェクト オーナーまたはプロジェクト作成者のロール プロジェクト オーナーは、監査ログで処理済みのバイト数と関連データを確認できます。プロジェクト作成者は、自身がオーナーである新しいプロジェクトを作成し、課金ログや監査ログを表示できます。
BigQuery データの編集者、オーナー、閲覧者のロール クエリのエラー メッセージを表示できます。
BigQuery Stackdriver Metrics Monitoring 閲覧者のロール 処理済みのバイト数や関連データなどのクエリの指標を表示できます。
Cloud Billing 閲覧者の権限 BigQuery の請求情報を表示できます。

  • 行レベルのアクセス ポリシーを使用してテーブルにクエリを実行するときに、クエリ期間を繰り返し観察することで、行レベルのアクセス ポリシーで保護されている可能性のある行の値を推測できます。このタイプの攻撃では、パーティショニング列やクラスタリング列の一連のキー値に対して、大量の再試行を行う必要があります。クエリ期間を観察または測定する際にノイズが発生しますが、繰り返し試行することで、信頼できる推定値が特定される可能性があります。このレベルの保護の影響を受ける場合は、別のテーブルを使用して、異なるアクセス制御要件の行を分離することをおすすめします。
  • 繰り返されることで、悪意のあるユーザーがエラー メッセージを監視し、機密情報が盗まれる可能性があります。悪意のあるユーザーが基になるテーブルへのアクセス権を取得した場合、クエリでゼロ除算の例外が返されると、保護されている行の値が盗まれる可能性があります。ユーザーが同じデータに対して直接クエリを実行できないようにセキュリティ対策を講じていても、値が盗まれる可能性があります。多くの場合、この種の攻撃では、行レベルのセキュリティが適用されたテーブルに対して大量の再試行が必要になります。
  • 課金される最大バイト数またはカスタム費用管理によりクエリジョブの制限を設定することで、クエリジョブの上限を超えたときのエラーをモニタリングし、クエリで処理されたバイト数を検索できる場合があります。ただし、この攻撃には大量のクエリが必要になります。
  • 繰り返しクエリを実行し、Cloud Billing で BigQuery の課金額を観察することで、行レベルのアクセス ポリシーで保護されている可能性のある行の値が推測される可能性があります。このタイプの攻撃では、パーティショニング列やクラスタリング列の一連のキー値に対して、大量の再試行を行う必要があります。この保護レベルの影響を受ける場合は、クエリに対する課金データへのアクセスを制限することをおすすめします。

また、行レベルのアクセス ポリシーの予期しない追加、変更、削除など、行レベルのセキュリティが設定されたテーブルでの不審なアクティビティについて、管理者が Cloud Audit Logs をモニタリングすることをおすすめします。

行レベルのアクセス ポリシーを再作成するときに、誤って不要なアクセス権を付与しないようにする

テーブルに行アクセス ポリシーを初めて追加するときに、クエリ結果のデータがすぐにフィルタリングされます。テーブルの最後の行レベルのアクセス ポリシーを削除したときに、行レベルのアクセス ポリシーのみを再作成しようとしても、意図した範囲よりも広範囲に制限されていないアクセス権を付与してしまう可能性があります。

テーブルの最後の行レベルのアクセス ポリシーを再作成する場合は、次のガイドラインに従って浸透に行うことをおすすめします。

  1. まず、テーブルのアクセス制御を使用して、テーブルに対するすべてのアクセス権を削除します。
  2. すべての行レベルのアクセス ポリシーを削除します。
  3. 目的の行レベルのアクセス ポリシーを再作成します。
  4. テーブルのアクセス制御を使用して、テーブルへのアクセス権を再度有効にします。

また、テーブルに新しい行レベルのアクセス ポリシーを作成してから、不要になった古い行レベルのアクセス ポリシーを削除することもできます。

組織間ではなく、組織内でのみ行レベルのセキュリティを使用する

行レベルのセキュリティ機能を組織間で使用しないでください。これにより、サイドチャネル攻撃によるデータ漏洩を防止し、機密データへのアクセスをより厳密に管理できます。

行レベルのセキュリティ機能は、組織内のセキュリティ制約についてのみ使用することをおすすめします(たとえば、組織、大企業、企業でデータを共有する場合など)。組織間または公共のセキュリティに対しては使用しないでください。

組織外では、データにアクセスできるユーザーをきめ細かく管理することはできません。組織内では、行レベルのアクセス ポリシーを使用して、テーブルに対するクエリの課金情報へのアクセスを許可するユーザーを制御できます。課金情報はサイドチャネル攻撃の攻撃ベクトルとなります。

Filtered Data Viewer ロールは慎重に使用する

行レベルのアクセス ポリシーを作成すると、ポリシーのプリンシパルに bigquery.filteredDataViewer ロールが自動的に付与されます。ポリシーにプリンシパルを追加または削除するには、DDL ステートメントを使用する必要があります。

ただし、IAM を介してテーブル、データセット、プロジェクトなどの上位リソースに bigquery.filteredDataViewer のロールを付与できます。ユーザーに bigquery.filteredDataViewer ロールを付与すると、そのユーザーは対象のテーブル、データセット、プロジェクト内のすべての行レベルのアクセス ポリシーで定義された行を表示できるようになります。

ただし、テーブルに bigquery.filteredDataViewer ロールを付与しても、ユーザーがテーブルのすべての行を表示できるようになるわけではありません。行レベルのアクセス ポリシーのすべてのフィルタ式を結合しても、テーブル全体に対するアクセスが可能になるとは限りません。

リソースに bigquery.filteredDataViewer のロールを付与する際は、慎重に検討することをおすすめします。

パーティション分割列でのフィルタはパフォーマンスに影響する

行レベルのアクセス ポリシーのフィルタは、パーティション分割テーブルとクラスタ化テーブルのクエリ プルーニングに使用されません。

行レベルのアクセス ポリシーでパーティション分割列を指定している場合、クエリ プルーニングのパフォーマンス上のメリットはありません。