このページでは、AlloyDB for PostgreSQL のパラメータ化されたセキュアビューについて説明します。このビューは、SQL ビューを使用して、アプリケーション データのセキュリティと行のアクセス制御を提供します。これにより、アプリケーション ユーザーが、アクセスする必要があるデータのみを表示できるようになります。
パラメータ化されたセキュアビューは PostgreSQL セキュアビューの拡張機能であり、ビュー定義でアプリケーション固有の名前付きビュー パラメータを使用できます。この機能は、クエリと名前付きパラメータの値を受け取るインターフェースを提供します。インターフェースは、その値を使用してクエリを実行します。この値は、クエリの実行全体で使用されます。
パラメータ化されたセキュアビューの例を次に示します。
CREATE VIEW secure_checked_items WITH (security_barrier) AS
SELECT bag_id, timestamp, location
FROM checked_items t
WHERE customer_id = $@app_end_userid;
パラメータ化されたセキュアビューをクエリするには、execute_parameterized_query ストアド プロシージャを使用するか、EXECUTE .. WITH VIEW PARAMETERS ステートメントを実行します。詳細については、AlloyDB パラメータ化されたセキュアなビューを使用してアプリケーション データのセキュリティを管理するをご覧ください。
パラメータ化されたセキュアビューのメリット
パラメータ化されたセキュアビューは、データベース レベルでのデータ セキュリティの管理に適しています。特に、自然言語から変換されたクエリなど、信頼できないソースからのアドホック クエリを扱う場合に適しています。これらのビューを使用すると、きめ細かいアクセス制御を柔軟に実装できます。
たとえば、お客様のチェックイン済み荷物を追跡するアプリケーションについて考えてみましょう。ユーザー ID が 12345 のお客様が「荷物はどこですか？」と質問したとします。このシナリオでは、パラメータ化されたセキュアビューにより、次のことが保証されます。
クエリで返される行は、クエリを送信したユーザーがアクセスできる行（ユーザー ID 12345 にリンクされている行など）のみになります。
セキュリティ リスクの軽減
パラメータ化されたセキュアビューは、エンドユーザーがデータベースで信頼できないクエリ（自然言語クエリなど）を実行した場合のセキュリティ リスクの軽減に役立ちます。たとえば次のようなリスクがあります。
- 悪意のあるプロンプト: ユーザーが基盤となるモデルを操作して、すべてのアプリケーション データにアクセスしようとする可能性があります。
- 広範囲の SQL クエリ: 悪意のないユーザークエリからでも、センシティブ データを公開する SQL クエリが大規模言語モデル（LLM）により生成される可能性があります。
パラメータ化されたセキュアビューを使用すると、個々のアプリケーション ユーザーが使用できる行の範囲を制限できます。この制御により、ユーザークエリのフレーズに関係なくデータ セキュリティが確保されます。
データアクセス管理
パラメータ化されたセキュアビューは、ユーザー数の増加に伴う、データアクセス管理の一般的な課題に対処します。
ユーザー管理の簡素化: パラメータ化されたセキュアビューを使用すると、単一のデータベース ロールですべてのエンドユーザーに対応できます。エンドユーザーごとに個別のデータベース ユーザーやデータベース ロールを作成する必要はありません。これにより、各エンドユーザーが自分のデータにのみアクセスするアプリケーションのユーザーと接続の管理を簡素化できます。
たとえば、顧客に自分の予約のみが表示される航空会社のアプリケーションでは、単一のパラメータ化されたセキュアビューを定義して、エンドユーザー ID をパラメータとして使用することで、単一のデータベース ロール（基盤となるテーブルではなくこのビューにアクセスできるロール）ですべてのユーザーに対応できます。これにより、ユーザー管理とデータベース接続が簡素化されます。
セキュリティ強化の効率化: パラメータ化されたセキュアビューには、アクセス制御が組み込まれています。ビューがクエリされると、ビューにアクセスするユーザーに関係なく、定義されたセキュリティ パラメータが常に適用されます。これとは対照的に、ベーステーブルの基盤となるセキュリティ ポリシーを自動的にビューに適用するには、追加の構成が必要になります。
行レベル セキュリティ（RLS）ポリシーなど、PostgreSQL の既存のセキュリティ メカニズムの詳細については、行セキュリティ ポリシーをご覧ください。
セキュリティ メカニズム
パラメータ化されたセキュアビューを使用すると、アプリケーション デベロッパーは次の方法でデータ セキュリティと行アクセスを制御できます。
WITH (security barrier)オプションを使用して作成されたビューは、ビューが処理を完了するまで、悪意を持って選択された関数や演算子に行から値が渡されないようにすることで、行レベルのセキュリティを提供します。WITH (security barrier)句の詳細については、ルールと権限をご覧ください。- 名前付きビュー パラメータを使用したパラメータ化により、アプリケーション レベルのセキュリティ（エンドユーザー認証など）に基づいてアプリケーションから提供される値でパラメータ化された、データベースの制限付きビューを表示できます。
- パラメータ化されたビューにアクセスするクエリに追加の制限を適用して、エンドユーザーからの信頼できないクエリ（自然言語から SQL を生成する AI によって生成されたクエリなど）を実行するアプリケーションに対処できます。これにより、パラメータ化されたセキュアビューによって提供されるセキュリティ エンベロープの回避とリソース使用量の管理を防ぐことができます。詳細については、クエリに適用される制限をご覧ください。
制限事項
パラメータ化されたビューフラグは、AlloyDB のすべてのインスタンスで個別に有効にする必要があります。パラメータ化されたビュー オブジェクトをプライマリ インスタンスで作成すると、読み取りプール インスタンスとクロスリージョン レプリカに伝播されますが、
parameterized_views.enabledフラグの設定は自動的に適用されないため、各インスタンスで手動で設定する必要があります。詳細については、始める前にをご覧ください。各インスタンスで
parameterized_views.enabledフラグを有効にしない限り、パラメータ化されたビューを読み取りプール インスタンスやクロスリージョン レプリカでクエリすることはできません。