행 액세스 정책 이해하기¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 행 액세스 정책 권한

• 행 액세스 정책 DDL

• 행 액세스 정책 사용하기

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

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

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

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

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 식이 간단한 정책은 일반적으로 매핑(즉, 조회) 테이블에 액세스하는 정책에 비해 성능이 우수합니다. 테이블 조회 수를 최소화하면 성능이 향상됩니다.

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

• (스칼라 SQL UDF 개요에서) 메모이제이션 가능 함수.

• (행 액세스 정책 사용하기 항목에서) 정책에서 메모이제이션 가능 함수 사용하기.

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

행 액세스 정책이 없는 경우 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_table 및 MAX 함수인 select max(c) from my_table 을 사용하는 것 등이 있습니다.

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

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

• 마스킹 또는 행 액세스 정책의 본문에서 CURRENT_DATABASE 또는 CURRENT_SCHEMA 함수를 지정하면 이 함수는 세션에 사용 중인 데이터베이스 또는 스키마가 아니라 보호된 테이블이 포함된 데이터베이스 또는 스키마를 반환합니다.

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

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 함수를 호출하는 정책 조건을 작성할 것을 권장합니다. 예는 다음을 참조하십시오.

• 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 POLICY 및 CREATE ROW ACCESS POLICY 섹션을 참조하십시오.

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

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

외부 테이블¶

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

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

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

스트림¶

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

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

뷰¶

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

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

구체화된 뷰¶

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

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

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

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

동적 테이블¶

행 액세스 정책, 마스킹 정책, 태그를 사용하여 동적 테이블을 만들 수 있습니다. 자세한 내용은 다음을 참조하십시오.

• CREATE DYNAMIC TABLE

• 증분 새로 고침 관련 추가 제한 사항

CREATE TABLE 문¶

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

CREATE TABLE … CLONE:

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

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

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

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

  • 테이블 또는 뷰가 소스 스키마/데이터베이스에 존재하고 동일한 스키마/데이터베이스의 정책에 대한 참조가 있는 경우 복제본 테이블 또는 뷰는 소스 스키마/데이터베이스의 정책 대신 해당 복제된 정책(대상 스키마/데이터베이스에 있음)에 매핑됩니다.

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

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

CREATE TABLE … LIKE:

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

CREATE TABLE … AS SELECT:

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

쿼리 프로필¶

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

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

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

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

행 액세스 정책을 호출해야 하는 쿼리 계획의 각 단계는 쿼리 계획의 해당 단계에 해당 값을 지정하는 operation 및 object 열을 생성합니다. 쿼리에서 행 액세스 정책이 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 함수를 호출하고 데이터베이스 역할을 공유하는 정책 조건을 작성합니다. 컨슈머로서 공유 데이터베이스 역할을 계정 역할에 부여합니다. 자세한 내용은 정책으로 보호되는 데이터 공유하기 섹션을 참조하십시오.

제한 사항:

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

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

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

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

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

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

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

• 외부 함수:

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

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

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

Snowflake Native App Framework¶

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

• 정책이 포함된 데이터 콘텐츠 공유에 대한 제한 사항.

• 프록시 뷰에 대한 정책 정의하기.

• 차단된 컨텍스트 함수.

Streamlit in Snowflake¶

Streamlit in Snowflake 앱에서 사용되는 행 액세스 정책은 행 액세스 정책의 본문에 컨텍스트 함수를 사용하는 데 제한이 있습니다. 자세한 내용은 다음을 참조하십시오.

• Streamlit in Snowflake 의 컨텍스트 함수 및 행 액세스 정책

• 예제: 행 액세스 정책이 적용된 테이블의 데이터에 CURRENT_USER를 사용하여 액세스하기

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

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

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

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

행 액세스 정책 권한¶

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

스키마의 모든 오브젝트에 대해 작업을 수행하려면 상위 데이터베이스 및 스키마에 대한 USAGE 권한.

행 액세스 정책 DDL¶

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

• CREATE ROW ACCESS POLICY

• ALTER ROW ACCESS POLICY

• DROP ROW ACCESS POLICY

• SHOW ROW ACCESS POLICIES

• DESCRIBE ROW ACCESS POLICY

• ALTER TABLE, ALTER EXTERNAL TABLE, ALTER VIEW (테이블 또는 뷰에서 정책 추가/삭제)

DDL 명령, 작업 및 권한 요약¶

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

스키마의 모든 오브젝트에 대해 작업을 수행하려면 상위 데이터베이스 및 스키마에 대한 USAGE 권한.

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

행 액세스 정책 살펴보기¶

공유 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의 거버넌스 영역에 액세스하기¶

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_REFERENCES 및 VIEWS 뷰가 포함될 수 있지만 이에 국한되는 것은 아닙니다.

태그가 지정된 오브젝트¶

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

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

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

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

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