이 문서에서는 SQL을 지원하면서 애플리케이션 데이터 보안 및 행 수준 액세스 제어를 제공하는 PostgreSQL용 AlloyDB의 파라미터화된 보안 뷰에 대해 설명합니다. 이러한 뷰는 데이터 값 추출(열에서 특정 데이터 부분을 가져오는 프로세스)을 지원하며 프롬프트 인젝션 공격으로부터 보호하는 데 도움이 됩니다.
파리미터화된 보안 뷰를 사용하면 최종 사용자가 액세스해야 하는 데이터만 보도록 하는 데 도움이 됩니다.
파라미터화된 뷰는 PostgreSQL 뷰의 확장 프로그램으로, 뷰 정의에서 애플리케이션별 명명된 뷰 파라미터를 사용할 수 있습니다.
이 기능은 쿼리와 명명된 파라미터의 값을 사용하는 인터페이스를 제공합니다. 뷰는 이러한 값으로 쿼리를 실행하며, 이 값은 해당 쿼리의 실행 전반에 걸쳐 사용됩니다.
execute_parameterized_query 저장 프러시저를 사용하거나 EXECUTE .. WITH VIEW PARAMETERS 문을 실행하여 뷰를 쿼리할 수 있습니다.
사용 사례
파라미터화된 보안 뷰는 자연어 쿼리에서 변환된 쿼리와 같이 신뢰할 수 없는 소스의 임시 쿼리에 대한 데이터베이스 수준의 데이터 보안 관리에 적합합니다. 예를 들어 데이터베이스가 여행객의 체크인된 수하물을 추적하는 애플리케이션을 생각해 보세요.
이러한 고객이 애플리케이션에 쿼리를 실행할 수 있습니다. 예를 들어 애플리케이션 사용자 ID가 12345인 고객은 애플리케이션에 '내 가방은 어디에 있어?'와 같은 쿼리를 입력할 수 있습니다.
파라미터화된 보안 뷰를 사용하여 AlloyDB가 이 쿼리를 실행하는 방식에 다음 요구사항을 적용할 수 있습니다.
쿼리는 데이터베이스 파라미터화된 보안 뷰에 나열된 데이터베이스 객체와 열만 읽을 수 있습니다.
쿼리는 쿼리를 제출한 사용자와 연결된 데이터베이스 행만 읽을 수 있습니다. 반환된 행은 ID 열 값이 12345인 사용자의 테이블 행과 데이터 관계가 있습니다.
파라미터화된 보안 뷰는 최종 사용자가 데이터베이스 테이블에서 자연어 쿼리와 같은 신뢰할 수 없는 쿼리를 실행할 수 있을 때 발생하는 보안 위험을 완화하는 데 도움이 됩니다. 보안 위험에는 다음이 포함됩니다.
사용자가 프롬프트 인젝션 공격을 제출하고 기본 모델을 조작하여 애플리케이션이 액세스할 수 있는 모든 데이터를 표시하려고 시도할 수 있습니다.
LLM이 데이터 보안상의 이유로 적절한 범위보다 더 넓은 SQL 쿼리를 생성할 수 있습니다. 이 보안 위험으로 인해 선의로 작성된 사용자 쿼리에 대한 응답에서 민감한 정보가 노출될 수 있습니다.
파라미터화된 보안 뷰를 사용하면 신뢰할 수 없는 쿼리가 데이터를 가져올 수 있는 테이블과 열을 정의할 수 있습니다. 이러한 뷰를 사용하면 개별 애플리케이션 사용자가 사용할 수 있는 행의 범위를 제한할 수 있습니다. 이러한 제한을 통해 사용자가 쿼리를 어떻게 작성하든 애플리케이션 사용자가 자연어 쿼리를 통해 볼 수 있는 데이터를 엄격하게 제어할 수도 있습니다.
보안 메커니즘
파라미터화된 보안 뷰는 다음 방법을 사용하여 애플리케이션 개발자에게 데이터 보안 및 행 액세스 제어를 제공합니다.
WITH (security barrier) 옵션을 사용하여 만든 뷰는 뷰가 작업을 완료할 때까지 악의적으로 선택된 함수와 연산자가 행의 값을 전달받지 못하도록 하여 행 수준 보안을 제공합니다. WITH (security barrier) 절에 관한 자세한 내용은 규칙 및 권한을 참조하세요.
명명된 뷰 파라미터를 사용한 파라미터화는 최종 사용자 인증과 같은 애플리케이션 수준 보안을 기반으로 애플리케이션에서 제공한 값으로 파라미터화된 데이터베이스의 제한된 뷰를 허용합니다.
파라미터화된 뷰에 액세스하는 쿼리에 대한 추가 제한사항을 적용하여 지정된 파라미터 값을 기반으로 뷰에서 검사를 이스케이프하는 공격을 방지합니다. 자세한 내용은 쿼리에 적용되는 제한사항을 참조하세요.
제한사항
파라미터화된 보안 뷰에 사용되는 API 중 하나를 사용하여 호출되는 사용자 정의 함수에서 파라미터화된 뷰를 참조하면 오류가 발생합니다. 상위 쿼리에서 파라미터화된 뷰를 직접 참조해야 합니다.
AlloyDB의 모든 인스턴스에서 파라미터화된 뷰 플래그를 별도로 사용 설정해야 합니다. 기본 인스턴스에서 생성된 파라미터화된 뷰 객체는 읽기 전용 복제본과 리전 간 복제본에 전파됩니다.
하지만 parameterized_views.enabled 플래그 설정은 자동으로 복제되지 않으며 각 인스턴스에서 수동으로 복제해야 합니다. 자세한 내용은 시작하기 전에를 참조하세요. 각 복제본 인스턴스에서 parameterized_views.enabled 플래그를 사용 설정하기 전에는 복제본에서 파라미터화된 뷰를 쿼리할 수 없습니다. 이 제한사항은 대기 인스턴스에는 적용되지 않습니다.
[[["이해하기 쉬움","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(UTC)"],[],[],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)."]]
