パラメータ化されたビューの概要

Bigtable では、パラメータ化されたビューを使用して、アプリケーション コンテキストに基づいて論理ビューのデータ範囲を動的にフィルタできます。このアプローチにより、アプリケーションが SQL インジェクションから保護され、複数の静的ビューの必要性が軽減されます。

機密情報を処理するために、Bigtable パラメータ化ビューは SQL クエリ テキストとは別の分離されたコンテキストを使用します。データベースはこれらの値をサーバーサイドでバインドするため、ユーザーと AI エージェントはクエリ パラメータを操作できません。クエリの記述方法に関係なく、データベースはデータアクセスを特定のコンテキストに自動的に制限します。

パラメータ化されたビューのメリット

パラメータ化されたビューは、データベース レベルでのデータ スコープの管理に適しています。特に、自然言語から変換されたフリーフォーム クエリを処理するアプリケーションに適しています。データ スコーピングは、クエリ結果を特定のデータ サブセットに制限するプロセスです。これらのビューを使用すると、次の処理を柔軟に実装できます。

  • ディープティア ID の伝播: ユーザーレベルで詳細なデータ権限を適用し、ユーザーが自分のデータ コンテキストにのみアクセスできるようにします。たとえば、アプリケーションは、ユーザーまたはテナントが指定された境界内の行のみを取得するようにできます。
  • ユーザー管理の簡素化: ユーザーごとに個別のロールを使用するのではなく、すべてのデータベース ユーザーに単一のデータベース ロールを使用します。
  • パラメータの分離: パラメータ化されたビューは、LLM またはエンドユーザーの制御外にある分離されたコンテキストとして値を渡すことで、リスクを軽減します。これらの値はクエリテキストとは別に保持されるため、クエリを生成するユーザーや AI エージェントが操作することはできません。
  • SQL インジェクションの軽減: アプリケーションを構築する際に、クエリテキスト内のパラメータをクライアント側で置き換えると、クエリの操作につながる可能性があります。パラメータ化されたビューは、クエリ構造の解析後にサーバーサイドでパラメータ バインディングを実行することで、このリスクを軽減します。これにより、攻撃者が制御する値でクエリの構造を変更できないため、SQL インジェクションを防ぐことができます。

たとえば、コレステロール値などの患者の医療記録を保存する健康管理アプリについて考えてみましょう。患者が自分のデータをクエリする場合、悪意のあるエージェントや不正な動作をするエージェントが、他の患者の記録を取得しようとするクエリを生成またはリクエストする可能性があります。パラメータ化されたビューを使用することで、アプリケーションはデータベース レベルで患者の分離を適用します。ビューは patient_id ビュー パラメータで定義されます。

CREATE VIEW patient_health_pv AS
(SELECT * FROM patient_health_records WHERE patient_id = CAST(VIEW_PARAMETERS('patient_id') AS BYTES))

クライアントが患者の cholesterol の測定値をクエリする場合:

SELECT readings['value'], readings['date']
FROM patient_health_pv
WHERE readings['test_name'] = 'cholesterol'

ビューがクエリされるため、Bigtable は分離されたパラメータ マップから patient_id 値を自動的にバインドして適用します。LLM またはエンドユーザーがこのフィルタを変更または破棄することはできません。これにより、ユーザーレベルのスコープ設定が確実になり、SQL インジェクション ベクトルが排除されます。

パラメータ化されたビューの仕組み

パラメータ化されたビューは、ビュー パラメータと呼ばれるメカニズムを使用して、ユーザー ID などのアプリケーション レベルのコンテキストをデータベースに安全に渡します。パラメータ化されたビューは、ビュー パラメータ値をクエリ リクエストとともに個別の分離されたコンテキストとして渡すことで、これを実現します。Bigtable はクエリの実行中にこのコンテキストにアクセスできますが、クエリ自体はコンテキストを読み取ったり変更したりできません。

VIEW_PARAMETERS() 関数は、ビュー定義内でこれらのパラメータにアクセスするための SQL インターフェースです。たとえば、クエリを実行するユーザーの ID に基づいてデータをフィルタするには、ビューの WHERE 句に次の内容を含めます。

CREATE VIEW purchase_history_pv AS
(SELECT * FROM purchases WHERE user_id = CAST(VIEW_PARAMETERS('user_id') AS BYTES))

VIEW_PARAMETERS() を使用して列修飾子をパラメータ化することもできます。これにより、ビューは指定されたアプリケーション コンテキストに基づいて特定のフィールドを動的に返すことができます。

CREATE VIEW specific_test_result_pv AS
SELECT
  tests[VIEW_PARAMETERS('test_name')] AS reading,
  _timestamp AS reading_time
FROM patients

標準のクエリ パラメータとの違い

ビュー パラメータは、標準のクエリ パラメータとは異なる動作をします。

  • 構文とコンテキスト: 標準クエリ パラメータは @param 構文を使用して定義され、ビュー定義内では宣言できません。クエリ内でのみ宣言できます。ビュー パラメータには VIEW_PARAMETERS('key') 関数を使用してアクセスします。この関数は、任意のクエリまたはビュー コンテキストで呼び出すことができます。
  • フェイルクローズ動作: VIEW_PARAMETERS('key') 参照を含むビュー定義がクエリされたが、対応する値がリクエストのビュー パラメータ マップで指定されていない場合、クエリは not found / missing parameter エラーで直ちに失敗します。これにより、構成が誤って適用された場合にデータ漏洩を防ぐことができます。

制限事項

パラメータ化されたビューには次の制限が適用されます。

  • パラメータ化されたビューは、論理ビューからのみ作成できます。Google Cloud CLI を使用して、新しいパラメータ化された論理ビューを作成します。既存の論理ビューを変更しない。
  • ビュー パラメータは文字列型の値のみをサポートします。ビューの SQL 定義でパラメータが異なるデータ型を表す場合は、パラメータ値を文字列として渡し、ビュー定義内でキャストする必要があります（例: CAST(VIEW_PARAMETERS('parameter_name') AS INT64)）。

次のステップ