행 액세스 정책 이해하기

이 항목에서는 행 액세스 정책 및 행 수준 보안을 소개합니다.

이 항목의 내용:

행 수준 보안이란 무엇입니까?

Snowflake는 행 액세스 정책을 사용하여 쿼리 결과에 반환할 행을 결정함으로써 행 수준 보안을 지원합니다. 행 액세스 정책을 사용하면 상대적으로 단순한 방식으로 행을 볼 수 있는 특정 역할 1개를 허용하거나 보다 복잡한 방식으로 정책 정의에 매핑 테이블 을 포함하여 쿼리 결과에서 행에 대한 액세스를 결정할 수 있습니다. 정책에 매핑 테이블 조회가 포함된 경우 중앙 집중식 매핑 테이블을 생성하고 보호된 테이블과 동일한 데이터베이스에 매핑 테이블을 저장합니다. 이는 정책이 IS_DATABASE_ROLE_IN_SESSION 함수를 호출하는 경우 특히 중요합니다. 자세한 내용은 함수 사용법 노트를 참조하십시오.

행 액세스 정책은 스키마 수준 오브젝트로서, 다음과 같은 문 타입에서 테이블 또는 뷰의 지정된 행을 볼 수 있는지 여부를 결정합니다.

행 액세스 정책에는 이러한 조건이 충족될 때 쿼리 런타임 시에 데이터를 변환하는 조건 및 함수가 정책 식에 포함될 수 있습니다. 정책 기반 방식은 업무 분리를 지원하여 거버넌스 팀이 민감한 데이터 노출을 제한할 수 있는 정책을 정의할 수 있도록 합니다. 또한, 이 방식에는 일반적으로 기본 데이터에 대한 전체 액세스 권한이 있는 오브젝트 소유자(즉, 테이블 또는 뷰와 같은 오브젝트에 대한 OWNERSHIP 권한이 있는 역할)가 포함될 수 있습니다. 단일 정책은 다른 테이블과 뷰에 동시에 설정할 수 있습니다.

행 액세스 정책 관리자는 테이블과 뷰에 행 액세스 정책을 적용할 수 있습니다.

현재 행 액세스 정책에서는 행 삽입 또는 표시되는 행의 업데이트나 삭제를 허용하지 않습니다.

오브젝트가 생성될 때 또는 오브젝트가 생성된 후에 테이블이나 뷰에 행 액세스 정책을 추가할 수 있습니다. 자세한 내용은 이 항목의 테이블 또는 뷰에 행 액세스 정책 적용하기 를 참조하십시오.

행 액세스 정책은 어떻게 작동합니까?

행 액세스 정책에는 Snowflake 데이터베이스 오브젝트(예: 테이블 또는 뷰)를 지정할 수 있는 식이 포함되어 있으며, 조건식 함수컨텍스트 함수 를 사용하여 지정된 컨텍스트에서 표시될 행을 결정합니다.

Snowflake는 쿼리를 실행한 연산자 역할이 아닌 정책 소유자 역할을 사용하여 정책 식을 평가합니다. 이 방식을 사용하면 쿼리 연산자가 행 액세스 정책의 매핑 테이블에 액세스할 필요가 없으므로 Snowflake가 쿼리 결과에 행을 반환하지 않습니다.

기존 행 액세스 정책을 업데이트하고 싶은데 정책의 현재 정의를 확인해야 할 경우 GET_DDL 함수를 호출하거나 DESCRIBE ROW ACCESS POLICY 명령을 실행하십시오.

그런 다음, ALTER ROW ACCESS POLICY 명령으로 행 액세스 정책 식을 업데이트할 수 있습니다. 이 명령은 테이블이나 뷰에서 행 액세스 정책을 삭제할 필요가 없습니다. 따라서 행 액세스 정책으로 보호되는 테이블이나 뷰는 정책 식이 업데이트되는 동안 보호된 상태로 유지됩니다.

쿼리 런타임 시점의 행 액세스 정책

쿼리 런타임 시점에 Snowflake에서 수행되는 프로세스는 다음과 같습니다.

  1. Snowflake는 데이터베이스 오브젝트에 행 액세스 정책이 설정되었는지 확인합니다. 정책이 데이터베이스 오브젝트에 추가되면 모든 행이 정책에 의해 보호됩니다.

  2. Snowflake는 데이터베이스 오브젝트의 동적 보안 뷰(즉, 보안 인라인 뷰)를 생성합니다.

  3. ALTER TABLE 또는 ALTER VIEW 명령에 지정된 열의 값(즉, 행 액세스 정책을 테이블 또는 뷰에 추가할 때)이 정책의 해당 매개 변수에 바인딩되고 정책 식이 평가됩니다.

  4. Snowflake는 사용자에 대한 쿼리 결과를 생성하고 쿼리 출력에는 TRUE 로 평가되는 정책 정의 기반 행만 포함됩니다.

특정 실행 계획에 대한 자세한 내용은 이 항목의 쿼리 프로필 섹션을 참조하십시오.

Snowflake는 테이블에 대한 행 액세스 정책 및 동일한 테이블의 뷰에 대한 행 액세스 정책 등과 같은 중첩 행 액세스 정책을 지원합니다. 쿼리 런타임 시점에 Snowflake는 지정된 쿼리와 관련된 모든 행 액세스 정책을 다음 순서로 평가합니다.

  • 테이블에 적용되는 행 액세스 정책이 항상 먼저 실행됩니다.

  • 뷰에 대한 정책은 테이블에 대한 정책을 평가한 후에 실행됩니다.

  • 중첩 뷰가 있는 경우(예: 테이블 1 -> 뷰 1 -> 뷰 2 -> 뷰 n), 왼쪽에서 오른쪽으로 순차적으로 정책이 적용됩니다.

이 패턴은 쿼리의 데이터와 관련한 행 액세스 정책의 수와 관계없이 진행됩니다. 다음 다이어그램은 쿼리 연산자, 테이블, 뷰 및 정책 사이의 관계를 보여줍니다.

테이블과 뷰가 포함된 행 액세스 정책입니다.

행 액세스 정책 권한, 명령 및 단계별 지침에 대한 자세한 내용은 다음을 참조하십시오.

대표적인 사용 사례: 단순한 행 필터링

행 액세스 정책에 대한 단순한 애플리케이션의 목적은 정책의 속성 및 쿼리 결과에서 해당 속성을 볼 수 있는 역할을 지정하는 것입니다. 이와 같이 단순한 정책의 이점은 매핑 테이블이 포함된 행 액세스 정책과 비교하여 Snowflake가 이러한 정책을 평가하여 쿼리 결과를 반환하기 위한 성능이 비용이 무시할 수 있는 수준이라는 점입니다.

대표적인 예에서와 같이, 정보 기술 관리자(예: it_admin 사용자 지정 역할)가 직원 식별 번호(즉, empl_id)를 쿼리한 후 직원에게 내부 시스템을 사용할 수 있는 추가 권한을 부여해야 합니다. 그러므로 CURRENT_ROLEit_admin 사용자 지정 역할과 일치하고 기타 모든 역할에 대한 행을 반환하지 않는 경우 행 액세스 정책에서는 쿼리 결과에서 행을 반환해야 합니다. 예:

CREATE OR REPLACE ROW ACCESS POLICY rap_it
AS (empl_id varchar) RETURNS BOOLEAN ->
  'it_admin' = current_role()
;
Copy

CURRENT_ROLE의 값을 제외하고 평가할 기타 조건이 없으므로 이 정책은 가장 간략한 행 액세스 정책입니다.

역할 계층 구조를 고려해야 하는 경우, 이 정책은 IS_ROLE_IN_SESSION 을 유사하게 사용하여 쿼리 결과에서 직원 ID를 볼 수 있는 다른 역할을 추가로 포함할 수 있습니다.

아니면 추가적인 조건을 고려하기 위해 CASE 함수를 사용하면 WHEN/THEN/ELSE 절을 포함하여 보다 자세한 조건부 논리를 지원할 수 있습니다.

대표적인 사용 사례: 매핑 테이블을 사용하여 쿼리 결과 필터링

행 액세스 정책 조건에서는 매핑 테이블을 참조하여 쿼리 결과 세트를 필터링할 수 있지만, 매핑 테이블을 사용하는 경우 보다 간단한 예에 비해 성능이 저하될 수 있습니다.

예를 들어, 매핑 테이블을 사용하여 영업 관리자가 지정된 영업 리전에서 볼 수 있는 수익 값을 결정해 보겠습니다. 매핑 테이블은 영업 관리자와 영업 리전(예: WW: 전 세계, NA: 북미, EU: 유럽 연합)을 지정해야 합니다.

영업 관리자

리전

Alice

WW

Bob

NA

Simon

EU

다음으로 1개 이상의 조건이 포함된 정책을 정의하여 하위 쿼리가 포함된 매핑 테이블을 쿼리합니다. 쿼리 런타임 시점에 Snowflake는 쿼리를 실행하는 사용자와 매핑 테이블에 지정된 판매 리전이 일치하는지 확인합니다.

일치하면 사용자는 쿼리 결과에서 해당 행을 볼 수 있습니다. 매핑 테이블에 따라 예상되는 쿼리 결과는 다음과 같습니다.

회사

리전

수익

볼 수 있는 사용자

Acme

EU

25억

Alice, Simon

Acme

NA

15억

Alice, Bob

매핑 테이블이 포함된 행 액세스 정책 구현과 관련된 자세한 내용은 다음을 참조하십시오.

정책 성능 지침

행 액세스 정책은 매우 다양한 실제 상황에서 잘 작동하도록 설계되었습니다. 데이터를 보호하고 성능을 향상하기 위한 다음의 팁을 활용하십시오.

정책 인자 제한:

Snowflake는 정책이 바인딩된 열을 스캔해야 하며, 이는 쿼리에서 참조되지 않는 경우에도 해당합니다. 그러므로 인자의 개수가 적은 정책이 일반적으로 인자의 개수가 많은 정책보다 성능이 우수합니다.

단순한 SQL 식:

CASE 문과 같이 SQL 식이 간단한 정책은 일반적으로 매핑(즉, 조회) 테이블에 액세스하는 정책에 비해 성능이 우수합니다. 테이블 조회 수를 최소화하면 성능이 향상됩니다.

매핑 테이블을 지정할 때 매핑 테이블 참조를 메모이제이션 가능 함수로 바꿉니다. 자세한 내용은 다음을 참조하십시오.

현실적인 워크로드로 테스트:

행 액세스 정책이 없는 경우 Snowflake가 이미 테이블의 행 수를 알고 있으므로 SELECT COUNT(*) FROM t1 쿼리가 몇 밀리초 내에 실행됩니다. 그러나 행 액세스 정책을 추가하면 Snowflake가 테이블을 스캔하여 현재 컨텍스트에서 액세스할 수 있는 행의 개수를 계산해야 합니다. 성능의 차이가 크지만 이 쿼리는 대부분의 실제 워크로드를 대표하지 않습니다.

이와 관련한 자세한 내용은 이 항목의 고려 사항 섹션을 참조하십시오.

속성을 기준으로 클러스터링:

매우 큰 테이블의 경우 정책 필터링에 사용되는 속성별로 클러스터링을 수행하면 성능이 향상될 수 있습니다.

자세한 내용은 클러스터링 키 및 클러스터링된 테이블 섹션을 참조하십시오.

검색 최적화 서비스:

검색 최적화 서비스는 마스킹 정책 또는 행 액세스 정책을 사용하는 테이블에서 쿼리 성능을 개선할 수 있습니다.

자세한 내용은 검색 최적화 서비스에서 마스킹 정책과 행 액세스 정책을 사용하는 테이블을 위한 지원 을 참조하십시오.

이점

행 액세스 정책의 주요 이점은 정책을 사용하면 조직이 확장 가능한 정책을 통해 데이터 보안, 거버넌스 및 분석의 균형을 적절하게 조정하는 것이 가능하다는 점입니다. 행 액세스 정책은 확장이 가능하므로, 언제든지 1개 이상의 조건을 추가하거나 제거하여 정책이 데이터, 매핑 테이블 및 RBAC 계층 구조에 대한 업데이트와 일치하도록 할 수 있습니다.

추가적인 이점은 다음과 같습니다.

사용 편의성:

정책을 한 번 작성하면 데이터베이스 및 스키마 전체에 적용할 수 있습니다.

변경 관리:

테이블에 정책을 다시 적용할 필요 없이 편리하게 행 액세스 정책의 정의를 변경할 수 있습니다.

매핑 테이블을 사용하는 경우에는 정책을 변경할 필요 없이 정책에서 참조하는 매핑 테이블의 권리 정보를 업데이트할 수 있습니다.

데이터 관리 및 SoD:

오브젝트 소유자가 아닌 중앙의 데이터 관리자가 보호할 오브젝트를 결정합니다. 행 액세스 정책은 업무 분리(즉, SoD)를 지원하는 중앙 집중식, 분산형 및 하이브리드 관리 모델을 통해 편리하게 관리 및 지원할 수 있습니다.

데이터 인증 및 거버넌스:

행 액세스 정책은 역할 또는 사용자 지정 권한에 따른 상황에 맞는 데이터 액세스를 지원합니다.

제한 사항

  • 행 액세스 정책으로 보호되는 뷰에서 CHANGES 절을 사용하는 기능은 지원되지 않습니다.

  • Snowflake는 행 액세스 정책에서 외부 테이블을 매핑 테이블로 사용하는 것을 지원하지 않습니다. 자세한 내용은 이 항목의 외부 테이블 섹션을 참조하십시오.

  • Snowflake는 스트림 오브젝트 자체에 행 액세스 정책을 연결하는 기능을 지원하지 않지만, 행 액세스 정책으로 보호되는 테이블에 스트림이 액세스할 때 테이블에 행 액세스 정책을 적용합니다. 자세한 내용은 이 항목의 스트림 섹션을 참조하십시오.

  • 행 액세스 정책에 대한 향후 권한 부여 는 지원되지 않습니다.

    해결 방법으로 APPLY ROW ACCESS POLICY 권한을 사용자 지정 역할에 부여하여 해당 역할이 테이블 또는 뷰에 행 액세스 정책을 적용하도록 허용하십시오.

고려 사항

  • 다른 행 액세스 정책이나 마스킹 정책으로 보호되는 테이블에 행 액세스 정책을 연결하면 오류가 발생할 수 있습니다. 자세한 내용은 ALTER TABLE, ALTER EXTERNAL TABLE, ALTER VIEW 를 참조하십시오.

  • 정책 본문에 하나 이상의 하위 쿼리 를 포함하면 오류가 발생할 수 있습니다. 가능하면 하위 쿼리 수를 제한하고 JOIN 작업 수를 제한하며 WHERE 절 조건을 단순화하십시오.

  • Snowflake는 테이블 및 뷰의 열에 대한 통계를 유지 관리하여 몇 밀리초 내에 여러 간단한 쿼리에 응답할 수 있습니다. 그러한 쿼리에 대한 예로는 COUNT 함수, select count(*) from my_tableMAX 함수인 select max(c) from my_table 을 사용하는 것 등이 있습니다.

    일반적으로 Snowflake는 쿼리가 액세스할 수 있는 행의 하위 세트를 식별해야 하므로 행 액세스 정책에는 이러한 통계 및 최적화를 적용할 수 없습니다. 행 액세스 정책이 적용된 테이블 및 뷰에서 이러한 타입의 쿼리를 실행하면 이러한 통계 및 최적화가 사용되지 않으므로 쿼리 결과가 제공되는 데 예상보다 시간이 오래 걸리며, 반환되는 통계는 “진정한” 통계 값이 아닌 액세스가 허용되는 항목만을 기반으로 합니다(즉, 행 액세스 정책이 제외된 테이블 또는 뷰에 대한 통계).

  • 버전이 지정된 스키마에 행 액세스 정책이 있는 경우 Snowflake Native App 에 대한 설정 스크립트를 생성할 때 주의하십시오. 자세한 내용은 버전 스키마 고려 사항 을 참조하십시오.

Snowflake 오브젝트 및 기능과 함께 행 액세스 정책 사용하기

다음 섹션에서는 다른 Snowflake 기능과 함께 행 액세스 정책이 테이블 및 뷰에 미치는 영향을 설명합니다.

행 액세스 정책을 사용하여 데이터베이스 오브젝트 가져오기

Information Schema POLICY_REFERENCES 테이블 함수는 주어진 오브젝트에 할당된 행 액세스 정책에 대한 정보를 반환할 수 있습니다.

  • 주어진 정책에 대한 모든 오브젝트:

    행 액세스 정책의 이름(예: mydb.policies.rap1)을 지정합니다.

    SELECT *
    FROM TABLE(
      mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
        POLICY_NAME=>'mydb.policies.rap1'
      )
    );
    
    Copy
  • 특정 오브젝트에 할당된 정책:

    오브젝트의 이름(예: mydb.tables.t1)과 오브젝트 도메인(예: table)을 지정합니다.

    SELECT *
    FROM TABLE(
      mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
        REF_ENTITY_NAME => 'mydb.tables.t1',
        REF_ENTITY_DOMAIN => 'table'
      )
    );
    
    Copy

이 테이블 함수는 Account Usage POLICY_REFERENCES 뷰에 상호 보완적입니다.

활성 역할 계층 구조 및 매핑 테이블

정책 조건은 세션에서 사용자의 활성 기본 역할과 보조 역할을 직접 평가하거나, 매핑 테이블에서 활성 역할을 조회하거나, 정책 관리자가 정책을 작성하려는 방식에 따라 둘 다 수행할 수 있습니다. 정책에 매핑 테이블 조회가 포함된 경우 중앙 집중식 매핑 테이블을 생성하고 보호된 테이블과 동일한 데이터베이스에 매핑 테이블을 저장합니다. 이는 정책이 IS_DATABASE_ROLE_IN_SESSION 함수를 호출하는 경우 특히 중요합니다. 자세한 내용은 함수 사용법 노트 를 참조하십시오.

이러한 사용 사례의 경우 Snowflake에서는 계정 역할을 지정할지 아니면 데이터베이스 역할을 지정할지 여부에 따라 IS_ROLE_IN_SESSION 또는 IS_DATABASE_ROLE_IN_SESSION 함수를 호출하는 정책 조건을 작성할 것을 권장합니다. 예는 다음을 참조하십시오.

테이블 또는 뷰에 행 액세스 정책 적용하기

테이블 또는 뷰에 행 액세스 정책을 추가하는 두 가지 옵션이 있습니다.

  1. 테이블이나 뷰에서 CREATE TABLE 문으로 테이블에 정책을 적용하거나 CREATE VIEW 문으로 뷰에 정책을 적용합니다.

  2. 기존 테이블이나 뷰에서 ALTER TABLE 문으로 테이블에 정책을 적용하거나 ALTER VIEW 문으로 뷰에 정책을 적용합니다.

테이블이나 뷰에 대해 다음 문을 실행합니다.

-- table
CREATE TABLE sales (
  customer   varchar,
  product    varchar,
  spend      decimal(20, 2),
  sale_date  date,
  region     varchar
)
WITH ROW ACCESS POLICY sales_policy ON (region);

-- view
CREATE VIEW sales_v WITH ROW ACCESS POLICY sales_policy ON (region)
AS SELECT * FROM sales;
Copy

기존 테이블이나 뷰에 대해 다음 문을 실행합니다.

-- table

ALTER TABLE t1 ADD ROW ACCESS POLICY rap_t1 ON (empl_id);

-- view

ALTER VIEW v1 ADD ROW ACCESS POLICY rap_v1 ON (empl_id);
Copy

마스킹 정책

데이터베이스 오브젝트에 행 액세스 정책과 1개 이상의 마스킹 정책 이 모두 있는 경우 Snowflake는 행 액세스 정책을 먼저 평가합니다.

행 액세스 정책 서명 또는 마스킹 정책 서명에서 주어진 테이블 또는 뷰 열을 지정할 수 있습니다. 다시 말해, 행 액세스 정책 서명과 마스킹 정책 서명에 모두 동시에 같은 열을 지정할 수 없습니다.

자세한 내용은 CREATE MASKING POLICYCREATE ROW ACCESS POLICY 섹션을 참조하십시오.

정책 작동 방식 시뮬레이션하기

POLICY_CONTEXT 함수를 호출하여 마스킹 정책으로 보호되는 열, 행 액세스 정책으로 보호되는 테이블 또는 뷰, 또는 두 가지 유형의 정책으로 모두 보호되는 열, 테이블 또는 뷰에 대한 쿼리를 시뮬레이션합니다.

외부 테이블

CREATE EXTERNAL TABLE 문을 실행하여 행 액세스 정책으로 외부 테이블을 만들고 VALUE 열에 정책을 적용할 수 있습니다.

외부 테이블에서 ALTER TABLE 문을 실행하여 기존 외부 테이블의 VALUE 열에 행 액세스 정책을 적용할 수 있습니다.

행 액세스 정책은 가상 열에 직접 추가할 수 없습니다. 대신, 외부 테이블에 뷰를 생성하고 뷰의 열에 행 액세스 정책을 적용해야 합니다.

중요

Snowflake는 행 액세스 정책에서 외부 테이블을 매핑 테이블로 사용하는 것을 지원하지 않습니다. 데이터베이스를 복제하는 동안 Snowflake는 행 액세스 정책을 복제하지만 외부 테이블은 복제하지 않습니다. 그러므로 복제된 데이터베이스의 정책은 복제된 데이터베이스에 없는 테이블을 참조하게 됩니다.

외부 테이블의 데이터가 행 액세스 정책에 필요한 경우에는 행 액세스 정책이 있는 데이터베이스 내의 전용 스키마로 외부 테이블 데이터를 이동한 후 복제 작업을 완료하는 것이 좋습니다. 행 액세스 정책을 업데이트하여 정책이 복제된 데이터베이스의 테이블을 참조하도록 정규화된 테이블의 이름을 참조합니다.

스트림

테이블에 행 액세스 정책이 추가되면 Snowflake는 스트림이 테이블 데이터에 액세스할 때 테이블 데이터에 행 액세스 정책을 적용합니다.

자세한 내용은 제한 사항 섹션을 참조하십시오.

Snowflake는 기본 테이블 및 뷰에 행 액세스 정책을 설정할 수 있는 기능을 지원합니다. 기본 테이블 또는 뷰 정책은 뷰 소유자(즉, INVOKER_ROLE) 또는 쿼리 연산자 역할(즉, CURRENT_ROLE)에만 적용할 수 있습니다.

자세한 내용은 제한 사항 섹션을 참조하십시오.

구체화된 뷰

Snowflake는 행 액세스 정책이 기본 테이블이나 뷰에 설정되지 않은 경우 구체화된 뷰에 행 액세스 정책을 추가하는 기능을 지원합니다.

행 액세스 정책 및 구체화된 뷰에 대한 제한 사항은 다음과 같습니다.

  • 행 액세스 정책이 기본 테이블에 추가된 경우에는 테이블에서 구체화된 뷰를 생성할 수 없습니다.

  • 기본 테이블에서 구체화된 뷰를 생성한 경우에는 테이블에 행 액세스 정책을 추가할 수 없습니다.

CREATE TABLE 문

다음은 행 액세스 정책이 CREATE TABLE 문에 영향을 주는 방법을 요약하여 보여줍니다.

CREATE TABLE … CLONE:

다음 방식은 복제된 오브젝트에 액세스할 때 테이블이나 뷰에 대한 SELECT 권한이 있는 사용자로부터 데이터를 보호하는 데 유용합니다.

  • 개별 정책 오브젝트를 복제하는 기능은 지원되지 않습니다.

  • 스키마를 복제하면 스키마 내의 모든 정책이 복제됩니다.

  • 복제된 테이블은 원본 테이블과 동일한 정책에 매핑됩니다. 즉, 기본 테이블이나 기본 테이블의 열에 정책이 설정되어 있으면 복제된 테이블이나 복제된 테이블의 열에 정책이 연결됩니다.

    • 테이블이 상위 스키마 복제 컨텍스트에서 복제되는 경우, 소스 테이블에 동일한 상위 스키마의 정책에 대한 참조(즉, 로컬 참조)가 있으면 복제된 테이블도 복제된 정책에 대한 참조를 갖습니다.

    • 소스 테이블이 다른 스키마(즉, 외부 참조)의 정책을 참조하는 경우 복제된 테이블에도 외부 참조가 유지합니다.

자세한 내용은 CREATE <오브젝트> … CLONE 섹션을 참조하십시오.

CREATE TABLE … LIKE:

기본 테이블에 행 액세스 정책이 설정된 경우 새 테이블의 열에 행 액세스 정책이 설정되지 액세스 않습니다. 새 테이블은 비어 있습니다.

CREATE TABLE … AS SELECT:

기본 테이블에 행 액세스 정책이 설정된 경우 새 테이블에는 행 액세스 정책의 정의에 따라 필터링된 행이 포함됩니다. 새 테이블의 열에는 행 액세스 정책이 설정되어 있지 않습니다.

쿼리 프로필

쿼리 런타임 시에 Snowflake는 동적 보안 뷰 를 생성합니다.

행 액세스 정책이 설정되어 있는 데이터베이스 오브젝트에 대해 EXPLAIN 명령을 사용하면 행 액세스 정책이 있다는 쿼리 결과가 제공됩니다. 데이터베이스 오브젝트에 행 액세스 정책이 설정되어 있는 경우 EXPLAIN 쿼리 결과는 다음의 열 값을 지정합니다.

  • operation 열에는 DynamicSecureView 값이 포함됩니다.

  • object 열에는 "<오브젝트_이름> (+ RowAccessPolicy)" 값이 포함됩니다.

행 액세스 정책을 호출해야 하는 쿼리 계획의 각 단계는 쿼리 계획의 해당 단계에 해당 값을 지정하는 operationobject 열을 생성합니다. 쿼리에서 행 액세스 정책이 1회만 호출되는 경우 EXPLAIN 쿼리 결과에서는 1개의 행에만 DynamicSecureView"<오브젝트_이름> (+ RowAccessPolicy)" 값이 포함됩니다.

EXPLAIN 명령 결과 및 쿼리 프로필 웹 인터페이스에서 Snowflake는 행 액세스 정책 정보 (즉, 정책 이름, 정책 서명, 정책 식) 또는 정책에서 액세스하는 오브젝트를 사용자에게 표시하지 않습니다.

다음 예는 1회만 호출되는 행 액세스 정책을 보여줍니다.

EXPLAIN SELECT * FROM my_table;
Copy
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step |   id   | parent |     operation     |           objects              | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
...

| 1     | 2      | 1      | DynamicSecureView | "MY_TABLE (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+

다음 예는 동일한 테이블에서 2회 호출되는 행 액세스 정책을 보여줍니다.

EXPLAIN SELECT product FROM sales
  WHERE revenue > (SELECT AVG(revenue) FROM sales)
  ORDER BY product;
Copy
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step  |   id   | parent |     operation     |           objects           | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
...
| 1      | 0      | [NULL] | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
...
| 2      | 2      | 1      | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+

Time Travel

Snowflake는 행 액세스 정책이 적용된 테이블 및 뷰에서 Time Travel을 지원합니다.

쿼리 실행 시, Snowflake는 쿼리 시점에 행 액세스 정책의 매핑 테이블을 평가합니다. 즉, Time Travel은 매핑 테이블에 영향을 주지 않습니다.

자세한 내용은 Time Travel 이해 및 사용하기 섹션을 참조하십시오.

복제

행 액세스 정책 및 해당 할당은 데이터베이스 복제 및 복제 그룹을 사용하여 복제할 수 있습니다.

데이터베이스 복제 의 경우, 다음 조건 중 하나가 참이면 복제 작업이 실패합니다.

  • 기본 데이터베이스가 Enterprise 이상 계정에 있고 정책이 포함되어 있지만, 복제가 승인된 1개 이상의 계정이 하위 에디션에 있습니다.

  • 기본 데이터베이스에 포함된 테이블 또는 뷰에 다른 데이터베이스의 행 액세스 정책에 대한 허상 참조 가 있습니다.

복제 그룹 에서 여러 데이터베이스를 복제할 때 데이터베이스 복제에 대한 현수 참조 동작을 피할 수 있습니다.

참고

장애 조치 또는 장애 복구 작업을 사용하는 경우 Snowflake 계정은 Business Critical Edition 이상이어야 합니다.

자세한 내용은 여러 계정에 걸쳐 복제 및 장애 조치 도입 섹션을 참조하십시오.

데이터 공유

사용법:
  • 공급자가 공유 테이블 또는 뷰에 정책을 할당하고 정책 조건이 CURRENT_ROLE 또는 CURRENT_USER 함수를 호출하거나 보안 UDF 를 호출하는 경우, Snowflake는 함수의 NULL 값 또는 컨슈머 계정의 UDF를 반환합니다.

    왜냐하면 공유되는 데이터의 소유자가 일반적으로 테이블 또는 뷰가 공유되는 계정의 사용자 또는 역할을 관리하지 않기 때문입니다. 이 문제를 해결하려면 정책 조건에서 CURRENT_ACCOUNT 함수를 사용하십시오.

    또는 공급자로서 IS_DATABASE_ROLE_IN_SESSION 함수를 호출하고 데이터베이스 역할을 공유하는 정책 조건을 작성합니다. 컨슈머로서 공유 데이터베이스 역할을 계정 역할에 부여합니다. 자세한 내용은 정책으로 보호되는 데이터 공유하기 섹션을 참조하십시오.

제한 사항:
  • 데이터 공유 공급자는 독자 계정 에서 정책을 만들 수 없습니다.

  • 데이터 공유 컨슈머는 공유 테이블 또는 뷰에 정책을 적용할 수 없습니다. 이를 해결하려면 공유 데이터베이스를 가져와 공유 테이블 또는 뷰에서 로컬 뷰를 만드십시오.

  • 데이터 공유 컨슈머는 서로 다른 두 공급자를 참조하는 공유 테이블 또는 뷰를 쿼리할 수 없습니다. 예:

    • rap1t1 이라는 테이블을 보호하는 행 액세스 정책이며, 여기서 t1 은 공급자의 share1 이라는 공유에 있습니다.

    • rap1 정책 조건은 t2 라는 매핑 테이블을 참조하며, 여기서 t2share2 와 다른 공급자에서 가져온 것입니다.

    • t1 에 대한 컨슈머 쿼리가 실패합니다.

    • t1 의 공급자가 t1 을 쿼리할 수 있습니다.

  • 외부 함수:

    Snowflake는 다음과 같은 경우에 오류를 반환합니다.

    • 공유 테이블이나 뷰에 할당된 정책이 외부 함수를 호출하도록 업데이트되는 경우.

    • 정책이 외부 함수를 호출하고 정책을 공유 테이블 또는 뷰에 할당하려고 하는 경우.

Snowflake Native App Framework

Snowflake Native App 과 함께 행 액세스 정책을 사용하는 방법에 대한 자세한 내용은 다음을 참조하십시오.

행 액세스 정책 관리하기

중앙 집중식, 하이브리드 또는 분산형 관리 방식 선택하기

행 액세스 정책을 효과적으로 관리하려면 행 필터링 방식에서 중앙 집중식, 분산형 또는 하이브리드 거버넌스 방식을 준수해야 하는지를 고려하는 것이 좋습니다.

다음 테이블은 이러한 3가지 방식 각각에 대한 몇 가지 고려 사항을 요약하여 제공합니다.

정책 동작

중앙 집중식

하이브리드

분산형

정책 만들기

거버넌스 책임자

거버넌스 책임자

개별 팀

열에 정책 적용

거버넌스 책임자

개별 팀

개별 팀

구문 예제는 DDL 명령, 작업 및 권한 요약 섹션을 참조하십시오.

모범 사례로, Snowflake는 조직에서 모든 관련 이해 관계자를 소집하여 환경에서 행 액세스 정책을 구현하기 위한 최상의 관리 방식을 결정하는 것을 권장합니다.

행 액세스 정책 권한

사용자가 행 액세스 정책을 생성, 설정 및 소유할 수 있는지 여부를 결정하기 위해 Snowflake에서 지원하는 행 액세스 정책 권한은 다음과 같습니다.

스키마의 모든 오브젝트에 대해 작업하려면 상위 데이터베이스 및 스키마에 대한 USAGE 권한도 필요합니다.

권한

사용법

CREATE

스키마에서 새 행 액세스 정책을 생성할 수 있습니다.

APPLY

테이블 또는 뷰에서 행 액세스 정책 에 대한 추가 및 삭제 작업을 실행할 수 있습니다.

전역 APPLY ROW ACCESS POLICY 권한(즉, ACCOUNT에 대한 APPLY ROW ACCESS POLICY)을 부여하면 테이블과 뷰에서의 DESCRIBE 작업 실행을 활성화하는 것임에 유의해 주십시오.

구문 예제는 DDL 명령, 작업 및 권한 요약 섹션을 참조하십시오.

OWNERSHIP

행 액세스 정책에 대한 모든 권한을 부여합니다. 행 액세스 정책의 대부분 속성을 변경하려면 필수입니다. 특정 오브젝트에 대해 한 번에 단 하나의 역할만 이 권한을 보유할 수 있습니다.

행 액세스 정책 DDL

행 액세스 정책의 관리를 위해 Snowflake에서 지원하는 DDL 명령 및 작업은 다음과 같습니다.

DDL 명령, 작업 및 권한 요약

다음 테이블은 행 액세스 정책 DDL 작업과 필요한 권한 사이의 관계를 요약하여 제공합니다.

스키마의 모든 오브젝트에 대해 작업하려면 상위 데이터베이스 및 스키마에 대한 USAGE 권한도 필요합니다.

작업

필요한 권한

행 액세스 정책 만들기

동일한 스키마에서 CREATE ROWACCESS POLICY 권한이 있는 역할.

행 액세스 정책 변경

행 액세스 정책에 대한 OWNERSHIP 권한이 있는 역할.

Add/Drop 행 액세스 정책

계정에 대한 APPLY ROW ACCESS POLICY 권한이 있는 역할 또는 데이터베이스 오브젝트에 대한 OWNERSHIP 권한 및 행 액세스 정책 오브젝트에 대한 APPLY 권한이 있는 역할.

행 액세스 정책 삭제

다음 중 하나: 행 액세스 정책에 대한 OWNERSHIP 권한을 보유한 역할 또는 . 행 액세스 정책이 있는 스키마에 대한 OWNERSHIP 권한을 보유한 역할.

행 액세스 정책 표시

다음 중 하나: . APPLY ROW ACCESS POLICY 권한, 또는 . 행 액세스 정책에 대한 OWNERSHIP 권한, 또는 . 행 액세스 정책에 대한 APPLY 권한을 보유한 역할.

행 액세스 정책 설명

다음 중 하나: APPLY ROW ACCESS POLICY 권한, 또는 . 행 액세스 정책에 대한 OWNERSHIP 권한, 또는 . 행 액세스 정책에 대한 APPLY 권한을 보유한 역할.

Snowflake는 오브젝트에 행 액세스 정책을 만들고 설정할 수 있는 다양한 권한을 지원합니다.

  1. rap_admin 사용자 지정 역할이 모든 오브젝트에 대한 행 액세스 정책을 만들고 설정하는 중앙 집중식 행 액세스 정책 관리 접근 방식의 경우, 다음 권한이 필요합니다.

    use role securityadmin;
    grant create row access policy on schema <db_name.schema_name> to role rap_admin;
    grant apply row access policy on account to role rap_admin;
    
    Copy
  2. 하이브리드 관리 접근 방식에서는, 쿼리 성능 최적화를 위해 일관된 정책 생성을 보장하고 개별 팀 또는 역할이 테이블과 뷰를 보호하도록 특정 행 액세스 정책에 대한 APPLY 권한을 갖도록 보장하기 위해 단일 역할에 CREATE ROW ACCESS POLICY 권한이 주어집니다.

    예를 들어, 사용자 지정 역할 finance_role 이 소유한 테이블과 뷰에 행 액세스 정책 rap_finance 를 추가할 권한을 이 역할에 부여할 수 있습니다.

    use role securityadmin;
    grant create row access policy on schema <db_name.schema_name> to role rap_admin;
    grant apply on row access policy rap_finance to role finance_role;
    
    Copy

SQL로 행 액세스 정책 모니터링하기

두 개의 서로 다른 Account Usage 뷰와 Information Schema 테이블을 통해 행 액세스 정책 사용을 모니터링할 수 있습니다.

행 액세스 정책 사용을 모니터링하는 방법을 결정하는 두 가지 일반적인 접근 방식을 생각해보면 도움이 될 수 있습니다.

행 액세스 정책 살펴보기

공유 SNOWFLAKE 데이터베이스의 Account Usage 스키마에서 ROW_ACCESS_POLICIES 뷰를 사용할 수 있습니다. 이 뷰는 Snowflake 계정의 모든 행 액세스 정책에 대한 카탈로그 입니다. 예:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ROW_ACCESS_POLICIES
ORDER BY POLICY_NAME;
Copy

할당 식별하기

Snowflake는 쿼리가 계정 또는 특정 데이터베이스를 대상으로 해야 하는지 여부에 따라 행 액세스 정책 할당을 식별하는 다양한 옵션을 지원합니다.

  • 계정 수준 쿼리:

    Account Usage POLICY_REFERENCES 뷰를 사용하여 행 액세스 정책이 있는 모든 테이블을 확인합니다. 예:

    SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
    ORDER BY POLICY_NAME, REF_COLUMN_NAME;
    
    Copy
  • 데이터베이스 수준 쿼리:

    모든 Snowflake 데이터베이스에는 Snowflake Information Schema 가 포함됩니다. Information Schema 테이블 함수 POLICY_REFERENCES 를 사용하여 특정 행 액세스 정책과 관련된 모든 오브젝트를 확인합니다.

    SELECT *
    FROM TABLE(
      my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
        POLICY_NAME => 'rap_t1'
      )
    );
    
    Copy

Snowsight 로 행 액세스 정책 모니터링하기

Snowsight Monitoring » Governance 영역을 사용하여 테이블, 뷰, 열과 함께 정책 및 태그 사용량을 모니터링하고 보고할 수 있습니다. DashboardTagged Objects 의 두 가지 서로 다른 인터페이스가 있습니다.

DashboardTagged Objects 인터페이스를 사용할 때 다음 세부 사항에 유의하십시오.

  • DashboardTagged Objects 인터페이스에는 실행 중인 웨어하우스가 필요합니다.

  • Snowsight 는 Dashboard 를 12시간마다 업데이트합니다.

  • Tagged Objects 정보 대기 시간은 최대 2시간까지 될 수 있으며 최대 1,000개의 오브젝트를 반환합니다.

Snowsight의 거버넌스 영역에 액세스하기

Governance 영역에 액세스하려면 Snowflake 계정이 Enterprise Edition 이상 이어야 합니다. 또한 다음 중 하나를 수행해야 합니다.

  • ACCOUNTADMIN 역할을 사용합니다.

  • GOVERNANCE_VIEWER OBJECT_VIEWER 데이터베이스 역할이 직접 부여된 계정 역할을 사용합니다.

    이러한 데이터베이스 역할 부여와 함께 계정 역할을 반드시 사용해야 합니다. 현재, Snowsight 는 테이블, 뷰, 데이터 액세스 정책, 태그에 대한 액세스 권한이 있는 역할 계층 구조와 사용자 정의 데이터베이스 역할을 평가하지 않습니다.

    계정 역할에 이러한 두 가지 데이터베이스 역할이 부여되었는지 확인하려면 SHOW GRANTS 명령을 사용하십시오.

    SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
    
    Copy
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
    | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
    |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
    

    계정 역할에 이러한 데이터베이스 역할 중 하나 또는 둘 다 부여되지 않은 경우 GRANT DATABASE ROLE 명령을 사용하고 SHOW GRANTS 명령을 다시 실행하여 권한 부여를 확인하십시오.

    USE ROLE ACCOUNTADMIN;
    GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
    GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
    SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
    
    Copy

    이러한 데이터베이스 역할에 대한 자세한 내용은 SNOWFLAKE 데이터베이스 역할 섹션을 참조하십시오.

대시보드

데이터 관리자는 Dashboard 인터페이스를 사용하여 다음과 같은 방법으로 태그 및 정책 사용을 모니터링할 수 있습니다.

  • 적용 범위: 테이블, 뷰 또는 열에 정책 또는 태그가 있는지 여부를 기준으로 개수와 백분율을 지정합니다.

  • 배포: 가장 자주 사용되는 정책과 태그를 나열하고 계수합니다.

적용 범위와 배포를 통해 데이터가 얼마나 잘 보호되고 태그가 지정되었는지에 관해 알 수 있습니다.

개수, 백분율, 정책 이름 또는 태그 이름을 선택하면 Tagged Objects 인터페이스가 열립니다. Tagged Objects 인터페이스는 Dashboard 에서 선택한 항목을 기준으로 필터를 자동으로 업데이트합니다.

모니터링 정보는 여러 Account Usage 뷰에서 복잡하고 쿼리 집약적인 작업 실행에 대한 대안 또는 보완책입니다.

이러한 뷰에는 COLUMNS, POLICY_REFERENCES, TABLES, TAG_REFERENCESVIEWS 뷰가 포함될 수 있지만 이에 국한되는 것은 아닙니다.

태그가 지정된 오브젝트

데이터 관리자는 이 테이블을 사용하여 Dashboard 의 적용 범위와 배포를 특정 테이블, 뷰 또는 열 목록에 빠르게 연결할 수 있습니다. 다음과 같이 테이블 결과를 수동으로 필터링할 수도 있습니다.

  • Tables 또는 Columns 를 선택합니다.

  • 태그의 경우 태그를 사용하거나 사용하지 않거나 특정 태그를 기준으로 필터링할 수 있습니다.

  • 정책의 경우 정책을 사용하거나 사용하지 않거나 특정 정책을 기준으로 필터링할 수 있습니다.

테이블에서 행을 선택하면 Data » Databases 에서 Table Details 또는 Columns 탭이 열립니다. 필요에 따라 태그 및 정책 할당을 편집할 수 있습니다.

행 액세스 정책 감사하기

행 액세스 정책 감사 및 거버넌스 작업을 간소화하기 위해 Snowflake가 지원하는 방식은 다음과 같습니다.

  • SHOW ROW ACCESS POLICIES 를 사용하여 계정에서 삭제되지 않은 행 액세스 정책 목록을 생성합니다.

  • 행 액세스 정책 관리자(즉, 행 액세스 정책 OWNERSHIP 권한 이 있는 사용자)는 Time Travel 또는 스트림 을 사용하여 행 액세스 정책에서 참조하는 매핑 테이블에 대한 과거 데이터를 캡처할 수 있습니다.

  • 지정된 사용자가 액세스할 수 있는 데이터를 확인하려면, 행 액세스 정책 관리자는 사용자 역할로 쿼리를 실행할 수 있습니다.

    • Snowflake는 CREATE ROW ACCESS POLICY 명령에서 이 동작을 지원하는 사용자 지정 논리로 행 액세스 정책 expression 정의를 지원합니다.

    • 현재 Snowflake는 이러한 작업을 지원하는 기본 방법(예: 전용 시스템 또는 컨텍스트 함수)을 제공하지 않습니다.

  • 지정된 행 액세스 정책에서 매핑 테이블을 사용하여 행 데이터에 액세스할 수 있는 역할 및 사용자 모집단을 결정하는 경우, 행 액세스 정책 소유자는 매핑 테이블을 쿼리하여 요청 시 승인된 사용자 액세스를 결정할 수 있습니다.

  • Snowflake는 계정 사용 QUERY_HISTORY 뷰 뷰에서 행 액세스 정책과 관련된 오류 메시지 정보를 캡처하고 로그로 기록합니다. 쿼리에서 오류가 발생하면 Snowflake는 쿼리 평가 중에 발생한 첫 번째 오류 메시지를 기록합니다. 행 액세스 정책 오류 메시지에 대한 자세한 내용은 행 액세스 정책 문제 해결하기 를 참조하십시오.

  • 데이터베이스 오브젝트에 대한 행 액세스 정책과 관련하여 지정된 사용자가 과거에 액세스한 데이터를 확인하려면, ROW_ACCESS_POLICIES Account Usage 뷰 및 POLICY_REFERENCES Information Schema 테이블 함수와 함께 Time Travel을 사용합니다.

    • 정책 및 매핑 테이블(있는 경우)이 변경되지 않은 경우 행 액세스 정책 관리자는 사용자 역할로 Time Travel 쿼리를 실행할 수 있습니다. CURRENT_ROLE 과 같은 해당 세션 매개 변수의 값은 쿼리 결과에서 확인할 수 있습니다.

    • 정책 또는 매핑 테이블이 변경된 경우 행 액세스 정책 관리자는 매핑 테이블에 대해 time travel 쿼리를 실행하고 지정된 문제 발생 시간의 행 액세스 정책을 다시 구성해야 합니다. 이러한 단계 이후에는 행 액세스 정책 관리자가 데이터 쿼리를 시작하고 분석을 진행할 수 있습니다.

행 액세스 정책 문제 해결하기

행 액세스 정책에 적용되는 동작 및 오류 메시지는 다음과 같습니다.

동작

오류 메시지

문제 해결 작업

행 액세스 정책을 설정할 수 없습니다(구체화된 뷰).

행 액세스 정책을 구체화된 뷰에 연결할 수 없습니다.

구체화된 뷰에서 행 액세스 정책을 설정할 수 있는지 확인합니다. 이 항목의 구체화된 뷰 를 참조하십시오.

행 액세스 정책을 생성할 수 없습니다(부울).

003551=SQL compilation error: 행 액세스 정책 반환 타입 ‘’{0}’’이(가) BOOLEAN 이 아닙니다.

행 액세스 정책 정의에는 RETURNS BOOLEAN 항목이 있어야 합니다. CREATE ROW ACCESS POLICY 에서와 같이 행 액세스 정책을 다시 작성하십시오.

행 액세스 정책을 생성할 수 없습니다(데이터베이스).

이 세션에 현재 데이터베이스가 없습니다. ‘USE DATABASE’를 호출하거나 정규화된 이름을 사용하십시오.

행 액세스 정책은 스키마 수준 오브젝트이므로 현재 세션에 대한 데이터베이스와 스키마를 정의하거나 CREATE ROW ACCESS POLICY 명령에서 정규화된 이름을 사용하십시오. 자세한 내용은 오브젝트 이름 확인 섹션을 참조하십시오.

행 액세스 정책을 생성할 수 없습니다(오브젝트 있음).

SQL 컴파일 오류: ‘<이름>’ 오브젝트가 이미 있습니다.

스키마의 행 액세스 정책은 이미 명시된 이름으로 존재하므로, 다른 name 값으로 행 액세스 정책을 다시 생성합니다.

행 액세스 정책을 생성할 수 없습니다(스키마 소유권).

SQL 액세스 제어 오류: ‘S1’ 스키마에 대한 작업 권한이 충분하지 않습니다.

이 항목의 DDL 명령, 작업 및 권한 요약 에서 행 액세스 정책을 생성할 수 있는 권한을 확인하십시오.

행 액세스 정책을 생성할 수 없습니다(스키마 사용).

SQL 컴파일 오류: ‘<스키마_이름>’ 스키마가 없거나 권한이 없습니다.

지정된 스키마가 있는지 확인하고 이 항목의 DDL 명령, 작업 및 권한 요약 에서 행 액세스 정책을 생성할 수 있는 권한을 확인하십시오.

행 액세스 정책을 설명할 수 없습니다(사용법만 해당).

SQL 컴파일 오류: ‘RLS_AUTHZ_DB.S_B.P1’ 행 액세스 정책이 없거나 권한이 없습니다.

행 액세스 정책이 있는 상위 데이터베이스 및 스키마에 대한 USAGE 권한으로는 행 액세스 정책에서 DESCRIBE 작업을 실행할 수 없습니다. 행 액세스 정책이 있는지 확인하고 이 항목의 DDL 명령, 작업 및 권한 요약 에서 행 액세스 정책을 설명할 수 있는 권한을 확인하십시오.

행 액세스 정책을 삭제할 수 없습니다. (유지 관리).

SQL 컴파일 오류: ‘RLS_AUTHZ_DB.S_B.P1’ 행 액세스 정책이 없거나 권한이 없습니다.

지정된 행 액세스 정책이 있는지 확인하고 이 항목의 DDL 명령, 작업 및 권한 요약 에서 행 액세스 정책을 삭제할 수 있는 권한을 확인하십시오.

행 액세스 정책에서 UNDROP 을 실행할 수 없습니다. (유지 관리)

지원되지 않는 기능 ‘UNDROP은 ROW_ACCESS_POLICY 타입의 오브젝트에서 지원되지 않습니다’.

행 액세스 정책을 복구하려면 CREATE ROW ACCESS POLICY 명령을 실행한 후 ALTER TABLE 또는 ALTER VIEW 에서와 같이 ALTER TABLE 또는 ALTER VIEW 명령을 사용하여 행 액세스 정책을 데이터베이스 오브젝트에 추가하십시오.

행 액세스 정책을 업데이트할 수 없습니다(이름/작업).

SQL 컴파일 오류: ‘ROW_ACCESS_POLICY’ 타입의 오브젝트가 발견되었지만, 지정되지 않은 타입 ‘MASKING_POLICY’입니다.

쿼리를 다시 확인하여 오브젝트의 이름과 오브젝트에 대해 의도한 작업을 확인하십시오. . . 예를 들어 Snowflake는 ALTER ROW ACCESS POLICY <이름>; 을 지원하지 않습니다. . . 대신, CREATE OR REPLACE ROW ACCESS POLICY 명령을 사용하여 행 액세스 정책을 업데이트하십시오. 행 액세스 정책 작업에 대한 자세한 내용은 이 항목의 DDL 명령, 작업 및 권한 요약 섹션을 참조하십시오.

Snowflake 기능 또는 서비스와 함께 행 액세스 정책을 사용할 수 없습니다(지원되지 않는 기능).

지원되지 않는 기능 ‘CREATE ON OBJECTS ENFORCED BY ROW ACCESS POLICY’.

일부 Snowflake 기능 및 서비스에서는 행 액세스 정책을 지원하지 않습니다. 자세한 내용은 이 항목의 제한 사항Snowflake 오브젝트 및 기능과 함께 행 액세스 정책 사용하기 를 참조하십시오.

행 액세스 정책을 업데이트할 수 없습니다(지원되지 않는 토큰).

지원되지 않는 기능 ‘TOK_ROW_ACCESS_POLICY’.

TOK 는 토큰을 나타내며, 쿼리가 지원되지 않고/않거나 부정확한 경우 반환될 수 있습니다. Snowflake의 SQL 컴파일러가 해당 쿼리의 처리 방법을 알 수 없습니다. . 예: alter row access policy p1_test set comment = 'test policy 1';. 이 예에서 ALTER 명령을 정책 오브젝트에서 직접 사용할 수 없으며, 이 항목의 DDL 명령, 작업 및 권한 요약 에서와 같이 ALTER TABLE 또는 ALTER VIEW 명령을 대신 사용하십시오.

다음 항목: