參數化安全檢視是 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 Omni 參數化安全檢視表管理應用程式資料安全性」。
參數化安全檢視表的好處
參數化安全檢視表非常適合用於管理資料庫層級的資料安全性，尤其是處理來自不受信任來源的臨時查詢時，例如從自然語言翻譯而來的查詢。這些檢視畫面提供彈性的方式，可實施精細的存取控管。
舉例來說，假設有一個應用程式會追蹤顧客的託運行李。使用者 ID 為 12345 的顧客詢問：「我的包包在哪裡？」在這個情境中，參數化安全檢視可確保下列事項：
查詢只會傳回提交查詢的使用者可存取的資料列，例如連結至使用者 ID 12345 的資料列。
降低安全風險
當使用者在資料庫執行不受信任的查詢 (例如自然語言查詢) 時，參數化安全檢視可協助降低安全風險。這些風險包括：
- 惡意提示：使用者可能會嘗試操控基礎模型，存取所有應用程式資料。
- 範圍廣泛的 SQL 查詢：大型語言模型 (LLM) 可能會產生 SQL 查詢，導致機密資料外洩，即使使用者查詢的意圖良好也可能發生這種情況。
使用參數化安全檢視，即可限制個別應用程式使用者可存取的資料列範圍。無論使用者如何表達查詢，這項控制選項都能確保資料安全性。
資料存取權管理
參數化安全檢視表可解決常見難題，協助您管理大量且不斷增加的使用者資料存取權。
- 簡化使用者管理：透過參數化安全檢視畫面，您可以使用單一資料庫角色為所有使用者提供服務，不必為每位使用者建立個別的資料庫使用者或角色。如果每個使用者只需要存取自己的資料，參數化安全檢視區塊可簡化應用程式的使用者和連線管理作業。舉例來說，在航空公司應用程式中，客戶只能查看自己的預訂，您可以定義單一參數化安全檢視表，並以使用者 ID 做為參數。這個檢視表可讓單一資料庫角色 (可存取檢視表，但無法存取基礎資料表) 為所有使用者提供服務，進而簡化使用者管理和資料庫連線。
- 簡化安全防護措施：參數化安全檢視區塊本身就內建存取權控管機制。查詢檢視畫面時，系統一律會強制執行定義的安全參數，無論存取檢視畫面的使用者是誰。如果沒有額外設定，基礎資料表上的基礎安全政策可能不會自動套用至檢視區塊，這與上述做法形成對比。
如要進一步瞭解 PostgreSQL 現有的安全機制，例如資料列層級安全性 (RLS) 政策，請參閱「資料列安全性政策」。
安全機制
參數化安全檢視區塊會控管查詢存取基礎資料的方式，多添一層安全防護。應用程式開發人員可透過下列方法，確保資料安全及控管列存取權：
- 使用
WITH (security barrier)選項建立的檢視表可提供資料列層級安全性，防止惡意選擇的函式和運算子在檢視表完成工作之前，從資料列傳遞值。如要進一步瞭解WITH (security barrier)子句，請參閱「規則和權限」。 - 使用具名檢視表參數進行參數化，可根據應用程式層級安全性 (例如使用者驗證)，由應用程式提供的值參數化，限制資料庫的檢視表。
- 對存取參數化檢視區塊的查詢強制執行額外限制，有助於執行來自使用者 (例如 AI 自然語言轉 SQL 生成的查詢) 的不受信任查詢。這可防止逸出參數化安全檢視區塊提供的安全範圍，並管理資源用量。詳情請參閱「查詢強制限制」。
限制
- 您必須在每個 AlloyDB Omni 執行個體上，分別啟用參數化檢視表旗標。在主要執行個體上建立的參數化檢視表物件，會傳播至讀取集區執行個體和跨區域副本。不過，系統不會自動套用
parameterized_views.enabled旗標設定，您必須在每個執行個體上手動設定。詳情請參閱「事前準備」。您必須先在每個執行個體上啟用parameterized_views.enabled旗標，才能在讀取集區執行個體或跨區域副本上查詢參數化檢視表。