您可以使用 execute_parameterized_query 預存程序查詢檢視區塊,也可以執行 EXECUTE .. WITH VIEW PARAMETERS 陳述式。
用途
參數化安全檢視畫面非常適合在資料庫層級管理資料安全,防範來自不受信任來源的臨時查詢,例如從自然語言查詢翻譯而來的查詢。舉例來說,假設某個應用程式的資料庫會追蹤旅客的託運行李。這些客戶可以對應用程式發出查詢。舉例來說,應用程式使用者 ID 為 12345 的顧客可以在應用程式中輸入查詢,例如「我的行李在哪裡?」
您可以使用參數化安全檢視區塊,對 AlloyDB 執行這項查詢的方式套用下列要求:
查詢只能讀取您在資料庫參數化安全檢視畫面中列出的資料庫物件和資料欄。
查詢只能讀取與提交查詢的使用者相關聯的資料庫列。傳回的資料列與使用者資料列有資料關係,後者的 ID 資料欄值為 12345。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# Parameterized secure views overview\n\n| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n|\n|\n| For information about access to this\n| release, see the\n| [access request page](https://docs.google.com/forms/d/16wliam2vok6sdBjYwJIgWV4hw7MW9x5iQ29UwPAKqB0/viewform).\n\nThis document describes parameterized secure views in AlloyDB for PostgreSQL, which\ngive application data security\nand row access control while supporting SQL. These views support *data value\nextraction* ---the process of retrieving specific data pieces from\ncolumns---and they help protect against\n[prompt injection attacks](https://en.wikipedia.org/wiki/Prompt_injection).\nParameterized secure views help ensure that end users can view only the data that\nthey are supposed to access.\n\nParameterized views are an extension of\n[PostgreSQL views](https://www.postgresql.org/docs/current/tutorial-views.html),\nwhich let you use application-specific named view parameters in view definitions.\nThis capability provides an interface that takes a query and values for the named\nparameters. The views execute the query with those values, which\nare used throughout the execution of that query.\n\nThe following is an example of a parameterized secure view: \n\n CREATE VIEW secure_checked_items WITH (security_barrier) AS\n SELECT bag_id, timestamp, location\n FROM checked_items t\n WHERE customer_id = $@app_end_userid;\n\nYou can query the views using the `execute_parameterized_query` stored procedure,\nor by running the `EXECUTE .. WITH VIEW PARAMETERS` statement.\n\n### Use cases\n\nParameterized secure views are well suited for data security administration at\nthe database level against ad hoc queries from untrusted sources, such as\nqueries translated from natural language queries. For example, consider an\napplication whose database tracks the checked-in luggage of traveling customers.\nThese customers can issue queries to the application. For example, a customer\nwith the application user ID 12345 can enter a query into the application like,\n\"Where is my bag?\"\n\nYou can use parameterized secure views to apply the following requirements to\nhow AlloyDB executes this query:\n\n- The query can read only the database objects and columns that you listed in your database parameterized secure views.\n- The query can read only the database rows that are associated with the user who submitted the query. The returned rows have a data relationship with the user's table row whose ID column value is `12345`.\n\nFor more information about configuring security and access control, see\n[Secure and control access to application data using parameterized secure views](/alloydb/docs/manage-application-data-security-parameterized-secure-views#configure).\n\nParameterized secure views help to mitigate security risks that occur when end\nusers are allowed to run untrusted queries, like natural language queries, on\nthe database table. Security risks include the following:\n\n- Users can submit prompt injection attacks and try to manipulate the underlying model to reveal all the data that the application has access to.\n- The LLM might generate SQL queries that are broader in scope than is appropriate for data security reasons. This security risk can expose sensitive data in response to even well-intentioned user queries.\n\nUsing parameterized secure views, you can define the tables and columns that\nuntrusted queries can pull data from. These views let you restrict the range of rows\navailable to an individual application user. These restrictions also let you tightly\ncontrol the data that application users can view through natural language\nqueries, regardless of how users phrase those queries.\n\n### Security mechanism\n\nParameterized secure views give application developers data security\nand row access control using the following methods:\n\n- Views created using the [`WITH (security barrier)`](https://www.postgresql.org/docs/current/rules-privileges.html) option provide row-level security by preventing maliciously-chosen functions and operators from being passed values from rows until after the view has done its work. For more information about the `WITH (security barrier)` clause, see [Rules and Privileges](https://www.postgresql.org/docs/current/rules-privileges.html).\n- Parameterization using named view parameters allows a restricted view of the database parameterized by values provided by the application based on application-level security such as end user authentication.\n- Enforcement of additional restrictions on queries accessing parameterized views that prevents attacks against escaping the checks in the views based on the given parameter values. For more information, see [Enforced restrictions on queries](/alloydb/docs/manage-application-data-security-parameterized-secure-views#restrictions).\n\nLimitations\n-----------\n\n- If a parameterized view is referenced in a user-defined function that is\n called using any of the [APIs used in parameterized secure views](/alloydb/docs/manage-application-data-security-parameterized-secure-views#query-parameterized-secure-view),\n an error occurs. You must directly reference the parameterized view\n in the parent query.\n\n- You must enable the parameterized view flag separately on every instance of\n AlloyDB. Parameterized view objects created on the primary\n instance are propagated to read-only replicas and cross-region replicas.\n However, the `parameterized_views.enabled` flag setting isn't replicated\n automatically and must be replicated manually on each instance. For more\n information, see [Before you begin](/alloydb/docs/manage-application-data-security-parameterized-secure-views#before-you-begin). You can't query parameterized views on the replica before you enable\n the `parameterized_views.enabled` flag on each replica instance. This\n limitation doesn't apply to the standby instance.\n\nWhat's next\n-----------\n\n- [Manage application data security using parameterized secure views](/alloydb/docs/manage-application-data-security-parameterized-secure-views).\n- [Secure and control access to application data using parameterized secure views](/alloydb/docs/secure-app-data-parameterized-secure-views)."]]