參數化安全檢視是 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旗標。