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

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

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

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

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

サイドチャネル攻撃は、システムから取得した情報を利用したセキュリティ攻撃です。必要以上に幅広い権限を持つ攻撃者は、サイドチャネル攻撃を開始し、課金、ロギング、システムメッセージを観察または検索して機密データを獲得する可能性があります。

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

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

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

例

行レベルのアクセスポリシーを使用してテーブルにクエリを実行するときに、クエリ期間を繰り返し観察することで、行レベルのアクセスポリシーで保護されている可能性のある行の値を推測できます。このタイプの攻撃では、パーティショニング列やクラスタリング列の一連のキー値に対して、大量の再試行を行う必要があります。クエリ期間を観察または測定する際にノイズが発生しますが、繰り返し試行することで、信頼できる推定値が特定される可能性があります。このレベルの保護の影響を受ける場合は、別のテーブルを使用して、異なるアクセス制御要件の行を分離することをおすすめします。
攻撃者がクエリジョブの上限（課金される最大バイト数やカスタムコスト管理など）を超過したときに発生したエラーをモニタリングすることで、クエリで処理されたバイト数を検索できる場合があります。ただし、この攻撃には大量のクエリが必要になります。
繰り返しクエリを実行し、Cloud Billing で BigQuery の課金額を観察することで、行レベルのアクセスポリシーで保護されている可能性のある行の値が推測される可能性があります。このタイプの攻撃では、パーティショニング列やクラスタリング列の一連のキー値に対して、大量の再試行を行う必要があります。このレベルの保護の影響を受ける場合は、クエリに対する課金データへのアクセスを制限することをおすすめします。

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

ユーザー権限を制限して、データの改ざんを制限する

テーブルへの書き込み権限を持つユーザーは、bq load コマンドまたは BigQuery Storage Write API を使用してテーブルにデータを挿入できます。これにより、書き込み権限を持つユーザーが他のユーザーのクエリ結果を変更できます。

管理者には、テーブルの書き込みアクセスと行レベルのアクセスポリシーについて別々の Google グループを作成することをおすすめします。フィルタされたテーブルの結果のみを表示するユーザーには、フィルタされたテーブルへの書き込みアクセス権を含めないでください。

行レベルのアクセスポリシーを再作成するときに、誤ってアクセスさせないようにする

ベストプラクティス: テーブルに存在する行レベルのアクセスポリシーが 1 つだけの場合は、CREATE OR REPLACE コマンドを使用して行レベルのアクセスポリシーを作成しないでください。代わりに、テーブルのアクセス制御を使用してテーブルへのすべてのアクセス権を削除し、必要に応じてポリシーを再作成してから、アクセス権を再度有効にします。

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

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

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

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

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

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

サブクエリ行レベルのアクセスポリシーの場合は、組織またはプロジェクト内でテーブルを作成して検索します。これにより、セキュリティが強化され、ACL の構成が簡素化されます。これは、ポリシーのターゲットと参照テーブルに対する bigquery.tables.getData 権限と、関連する列レベルのセキュリティ権限が、権限付与者に必要となるためです。

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

例

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

行レベルのアクセスポリシーで `Filtered Data Viewer` ロールを管理する

ベストプラクティス: bigquery.filteredDataViewer は、行レベルのアクセスポリシーによって付与されるシステム管理ロールです。行レベルのアクセスポリシーでのみロールを管理します。Identity and Access Management（IAM）でロールを適用しないでください。

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

テーブル、データセット、プロジェクトなどの上位リソースに IAM を介して bigquery.filteredDataViewer のロールを付与しないでください。この方法でロールを付与すると、ユーザーは、意図した制限に関係なく、そのスコープ内のすべての行レベルのアクセスポリシーで定義された行を表示できます。行レベルのアクセスポリシーフィルタの結合がテーブル全体を網羅していない場合でも、この方法は重大なセキュリティリスクをもたらし、行レベルのセキュリティの目的を損ないます。

bigquery.filteredDataViewer ロールは、行レベルのアクセスポリシーでのみ管理することをおすすめします。この方法では、各ポリシーに定義されたフィルタ述語に従って、プリンシパルに bigquery.filteredDataViewer ロールが暗黙的に正しく付与されます。

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

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

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