BigQuery の行レベルのセキュリティに関するベスト プラクティス
このドキュメントでは、行レベルのセキュリティを使用する場合のベスト プラクティスについて説明します。
このドキュメントを読む前に、BigQuery の行レベルのセキュリティの概要および行レベルのセキュリティの操作をお読みになり、行レベルのセキュリティを理解してください。
ユーザー権限を制限してサイドチャネル攻撃を防ぐ
サイドチャネル攻撃は、システムから取得した情報を利用したセキュリティ攻撃です。必要以上に幅広い権限を持つ攻撃者は、サイドチャネル攻撃をより簡単に開始し、課金、ロギング、システム メッセージを観察または検索して機密データを獲得する可能性があります。
このような機会を減らすために、BigQuery では、テーブルに対するすべてのクエリで機密統計情報を非表示にします。これらの機密統計情報には、処理されたバイト数、処理されたパーティション数、課金されるバイト数、クエリプランのステージが含まれます。
センシティブ データへのアクセス権を付与しないように、管理者はフィルタされたデータのみを表示するユーザーに次の権限を付与しないようにすることをおすすめします。
| 権限 | センシティブ データ |
|---|---|
| プロジェクト オーナーまたはプロジェクト作成者のロール | プロジェクト オーナーは、監査ログで処理済みのバイト数と関連データを確認できます。プロジェクト作成者は、自身がオーナーである新しいプロジェクトを作成し、課金ログや監査ログを表示できます。 |
| BigQuery データの編集者、オーナー、閲覧者のロール | クエリのエラー メッセージを表示できます。 |
| Cloud Billing 閲覧者の権限 | BigQuery の請求情報を表示できます。 |
例
- 行レベルのアクセス ポリシーを使用してテーブルにクエリを実行するときに、クエリ期間を繰り返し観察することで、行レベルのアクセス ポリシーで保護されている可能性のある行の値を推測できます。このタイプの攻撃では、パーティショニング列やクラスタリング列の一連のキー値に対して、大量の再試行を行う必要があります。クエリ期間を観察または測定する際にノイズが発生しますが、繰り返し試行することで、信頼できる推定値が特定される可能性があります。このレベルの保護の影響を受ける場合は、別のテーブルを使用して、異なるアクセス制御要件の行を分離することをおすすめします。
- 攻撃者がクエリジョブの上限（課金される最大バイト数やカスタムコスト管理など）を超過したときに発生したエラーをモニタリングすることで、クエリで処理されたバイト数を検索できる場合があります。ただし、この攻撃には大量のクエリが必要になります。
- 繰り返しクエリを実行し、Cloud Billing で BigQuery の課金額を観察することで、行レベルのアクセス ポリシーで保護されている可能性のある行の値が推測される可能性があります。このタイプの攻撃では、パーティショニング列やクラスタリング列の一連のキー値に対して、大量の再試行を行う必要があります。このレベルの保護の影響を受ける場合は、クエリに対する課金データへのアクセスを制限することをおすすめします。
また、行レベルのアクセス ポリシーの予期しない追加、変更、削除など、行レベルのセキュリティが設定されたテーブルでの不審なアクティビティについて、管理者が Cloud Audit Logs（/bigquery/docs/reference/auditlogs）をモニタリングすることをおすすめします。
ユーザー権限を制限して、データの改ざんを制限する
テーブルへの書き込み権限を持つユーザーは、bq load コマンドまたは BigQuery Storage Write API を使用してテーブルにデータを挿入できます。これにより、書き込み権限を持つユーザーが他のユーザーのクエリ結果を変更できます。
管理者には、テーブルの書き込みアクセスと行レベルのアクセス ポリシーについて別々の Google グループを作成することをおすすめします。フィルタされたテーブルの結果のみを表示するユーザーには、フィルタされたテーブルへの書き込みアクセス権を含めないでください。
行レベルのアクセス ポリシーを再作成するときに、誤ってアクセスさせないようにする
テーブルに行アクセス ポリシーを初めて追加するときに、クエリ結果のデータがすぐにフィルタリングされます。テーブルの最後の行レベルのアクセス ポリシーを削除したときに、行レベルのアクセス ポリシーのみを再作成しようとしても、意図した範囲よりも広範囲に制限されていないアクセス権を付与してしまう可能性があります。
テーブルの最後の行レベルのアクセス ポリシーを再作成する場合は、次のガイドラインに従って浸透に行うことをおすすめします。
- まず、テーブルのアクセス制御を使用して、テーブルに対するすべてのアクセス権を削除します。
- すべての行レベルのアクセス ポリシーを削除します。
- 目的の行レベルのアクセス ポリシーを再作成します。
- テーブルへのアクセスを再度有効にします。
また、テーブルに新しい行レベルのアクセス ポリシーを作成してから、不要になった古い行レベルのアクセス ポリシーを削除することもできます。
組織間ではなく、組織内でのみ行レベルのセキュリティを使用する
行レベルのセキュリティ機能を組織間で使用しないでください。これにより、サイドチャネル攻撃によるデータ漏洩を防止し、センシティブ データへのアクセスをより厳密に管理できます。
サブクエリ行レベルのアクセス ポリシーの場合は、組織またはプロジェクト内でテーブルを作成して検索します。これにより、セキュリティが強化され、ACL の構成が簡素化されます。これは、ポリシーのターゲットと参照テーブルに対する bigquery.tables.getData 権限と、関連する列レベルのセキュリティ権限が、権限付与者に必要となるためです。
行レベルのセキュリティ機能は、組織内のセキュリティ制約についてのみ使用することをおすすめします（たとえば、組織、大企業、企業でデータを共有する場合など）。組織間または公共のセキュリティに対しては使用しないでください。
例
組織外では、データにアクセスできるユーザーをきめ細かく管理することはできません。組織内では、行レベルのアクセス ポリシーを使用して、テーブルに対するクエリの課金情報へのアクセスを許可するユーザーを制御できます。課金情報はサイドチャネル攻撃の攻撃ベクトルとなります。
Filtered Data Viewer ロールは慎重に使用する
行レベルのアクセス ポリシーを作成すると、ポリシーのプリンシパルに bigquery.filteredDataViewer ロールが自動的に付与されます。ポリシーにプリンシパルを追加または削除するには、DDL ステートメントを使用する必要があります。
ただし、IAM を介してテーブル、データセット、プロジェクトなどの上位リソースに bigquery.filteredDataViewer のロールを付与できます。ユーザーに bigquery.filteredDataViewer ロールを付与すると、そのユーザーは対象のテーブル、データセット、プロジェクト内のすべての行レベルのアクセス ポリシーで定義された行を表示できるようになります。
ただし、テーブルに bigquery.filteredDataViewer ロールを付与しても、ユーザーがテーブルのすべての行を表示できるようになるわけではありません。行レベルのアクセス ポリシーのすべてのフィルタ式を結合しても、テーブル全体に対するアクセスが可能になるとは限りません。
リソースに bigquery.filteredDataViewer のロールを付与する際は、慎重に検討することをおすすめします。
パーティション分割列でのフィルタはパフォーマンスに影響する
行レベルのアクセス ポリシーのフィルタは、パーティション分割テーブルとクラスタ化テーブルのクエリ プルーニングに使用されません。
行レベルのアクセス ポリシーでパーティション分割列を指定している場合、クエリ プルーニングのパフォーマンス上のメリットはありません。