AlloyDB for PostgreSQL 的參數化安全檢視表可讓您強制執行應用程式層級的資料列存取控管，確保使用者只能查看有權存取的資料。這些檢視表是 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 查詢：大型語言模型 (LLM) 可能會生成公開機密資料的 SQL 查詢，即使使用者查詢的出發點是善意的。
使用參數化安全檢視，即可限制個別應用程式使用者可存取的資料列範圍。無論使用者如何表達查詢內容，這項控制項都有助於保護應用程式資料。
資料存取權管理
參數化安全檢視表可解決管理資料存取權時常見的難題，
簡化使用者管理：使用參數化安全檢視表，您就能透過單一資料庫角色為所有使用者提供服務，不必為每位使用者建立個別資料庫使用者或角色。如果應用程式的每位使用者只需要存取自己的資料，參數化安全檢視區塊可簡化使用者和連線管理。
舉例來說，在航空公司應用程式中，客戶只能查看自己的預訂，您可以定義單一參數化安全檢視表，並以使用者 ID 做為參數。這個檢視表可讓單一資料庫角色 (可存取檢視表，但無法存取基礎資料表) 為所有使用者提供服務，進而簡化使用者管理和資料庫連線。
簡化安全措施：參數化安全檢視表本身就包含存取控管機制。查詢檢視表時，無論是哪位使用者存取檢視表，系統都會一律強制執行定義的安全參數。相較之下，如果基礎資料表有基礎安全性政策，可能不會自動套用至檢視表，必須額外設定。
如要進一步瞭解 PostgreSQL 現有的安全機制，例如資料列層級安全性 (RLS) 政策，請參閱「資料列安全性政策」。
安全機制
參數化安全檢視區塊可讓應用程式開發人員使用下列方法，控管資料安全性和資料列存取權：
- 使用
WITH (security_barrier)選項建立的檢視表可提供資料列層級安全性，防止惡意選擇的函式和運算子在檢視表完成工作之前，從資料列傳遞值。如要進一步瞭解WITH (security_barrier)子句，請參閱「規則和權限」。 - 使用具名檢視表參數進行參數化，可根據應用程式層級安全性 (例如使用者驗證)，由應用程式提供的值參數化資料庫，進而限制檢視表。
- 如果應用程式會執行使用者提供的未受信任查詢 (例如 AI 自然語言轉 SQL 生成的查詢)，則對存取參數化檢視表的查詢強制執行額外限制，會很有幫助。這項強制執行措施可防止查詢超出參數化安全檢視區塊提供的安全範圍，並協助管理資源用量。如要進一步瞭解查詢限制，請參閱「查詢強制限制」。
限制
您必須在每個 AlloyDB 執行個體上，分別啟用參數化檢視表旗標。在主要執行個體上建立的參數化檢視表物件，會傳播至讀取集區執行個體和跨區域副本。不過，系統不會自動套用
parameterized_views.enabled旗標設定，您必須在每個執行個體上手動設定。詳情請參閱「事前準備」。您必須先在每個執行個體上啟用
parameterized_views.enabled旗標，才能在讀取集區執行個體或跨區域副本上查詢參數化檢視表。