Column-level Security 이해하기¶

마스킹 정책이란 무엇입니까?¶

Snowflake는 스키마 수준 오브젝트로 마스킹 정책을 지원하여 권한이 부여된 사용자가 쿼리 런타임 시에 민감한 데이터에 액세스하는 것을 허용하는 동시에 민감한 데이터를 무단 액세스로부터 보호합니다. 즉, Snowflake에서 민감한 데이터는 기존 테이블에서 수정되지 않습니다(즉, 정적 마스킹 없음). 대신, 사용자가 마스킹 정책이 적용되는 쿼리를 실행할 때 마스킹 정책 조건에 따라 권한이 없는 사용자가 마스킹된 데이터, 부분적으로 마스킹된 데이터, 난독화된 데이터 또는 토큰화된 데이터를 볼 수 있는지 여부가 결정됩니다. 마스킹 정책이 스키마 수준 오브젝트로 제공되므로 중앙 집중식, 분산형 또는 하이브리드 관리 방식을 유연하게 선택할 수 있습니다. 자세한 내용은 이 항목의 Column-level Security 관리하기 섹션을 참조하십시오.

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

예를 들어, 마스킹 정책 관리자는 분석가(즉, 사용자 지정 ANALYST 역할이 있는 사용자)가 전화번호의 마지막 4자리만 볼 수 있고 소셜 시큐리티 번호는 볼 수 없지만, 고객 지원 담당자(예: 사용자 지정 SUPPORT 역할이 있는 사용자)는 고객 확인 사용 사례에 대한 전체 전화번호 및 소셜 시큐리티 번호를 볼 수 있도록 마스킹 정책을 구현할 수 있습니다.

마스킹 정책은 단일 데이터 타입, 1개 이상의 조건, 1개 이상의 마스킹 함수로 구성됩니다.

• 사용자는 데이터 타입이 일치하는 1개 이상의 테이블/뷰 열에 마스킹 정책을 적용할 수 있습니다. 예를 들어, 이메일 주소에 대한 정책을 한 번 정의한 후 데이터베이스 및 스키마 전체에서 수천 개의 이메일 열에 적용하는 것이 가능합니다.

• 마스킹 정책 조건은 조건식 함수 및 컨텍스트 함수 를 사용하거나 사용자 지정 권리 유형 테이블을 쿼리하여 표현할 수 있습니다. 사용자는 뷰 및 공유와 함께 사용하기 위해 각각 컨텍스트 함수 INVOKER_ROLE 및 INVOKER_SHARE 를 사용할 수 있습니다.

• 마스킹 함수는 기본 제공 함수(예: REGEXP_REPLACE, SHA2 , SHA2_HEX), 사용자 정의 함수 개요 또는 외부 함수 쓰기 (외부 토큰화 공급자를 사용한 토큰화 해제를 위해)일 수 있습니다.

Snowflake는 보안 뷰 를 제공하여 민감한 데이터에 대한 액세스를 제한하지만, 보안 뷰에는 뷰의 수가 많고 각 뷰에서 파생된 비즈니스 인텔리전스(BI) 대시보드로 인해 관리 상의 문제가 있습니다. 마스킹 정책은 관리할 뷰와 대시보드가 폭발적으로 증가하는 것을 방지함으로써 이러한 관리 문제를 해결합니다.

마스킹 정책은 오브젝트 소유자와 정책 관리자의 역할을 분리하여 업무 분리(SoD)를 지원합니다. 보안 뷰는 SoD를 제공하지 않으므로 활용성이 매우 제한됩니다. 이러한 역할 분리로 인해 다음과 같은 기본 설정이 필요합니다.

• 오브젝트 소유자(즉, 오브젝트에 대한 OWNERSHIP 권한이 있는 역할)에는 마스킹 정책의 설정을 해제할 수 있는 권한이 없습니다.

• 오브젝트 소유자는 마스킹 정책이 적용되는 열의 데이터를 볼 수 없습니다.

역할 및 권한 관리에 대한 자세한 내용은 Column-level Security 관리하기 (이 항목) 및 액세스 제어 권한 을 참조하십시오.

-- Dynamic Data Masking

CREATE MASKING POLICY employee_ssn_mask AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
    ELSE '******'
  END;

-- External Tokenization

  CREATE MASKING POLICY employee_ssn_detokenize AS (val string) RETURNS string ->
  CASE
    WHEN CURRENT_ROLE() IN ('PAYROLL') THEN ssn_unprotect(VAL)
    ELSE val -- sees tokenized data
  END;

이점¶

다음 테이블에서는 Dynamic Data Masking과 External Tokenization의 이점을 비교합니다.

제한 사항¶

다음 테이블은 Column-level Security에 대한 현재 제한 사항을 설명합니다. 확인 표시(즉, ✔)는 현재 해당 기능에 대한 지원이 제한되거나 부족함을 나타냅니다.

고려 사항¶

• 소스 열에 대한 마스킹 정책이 있는 소스 열의 값을 대상 열에 대한 마스킹 정책이 없는 대상 열로 삽입하는 경우에는 주의해야 합니다. 마스킹 정책은 소스 열에 설정되어 있으므로 마스킹되지 않은 열 데이터를 볼 수 있는 역할은 마스킹되지 않은 데이터를 다른 열에 삽입할 수 있습니다. 여기서, 테이블 또는 뷰에 대한 충분한 권한이 있는 역할은 값을 볼 수 있습니다.

• 소스 열에서 마스킹된 데이터를 보는 역할이 해당 값을 대상 열에 삽입하면, 삽입된 값은 마스킹된 상태를 유지됩니다. 마스킹 정책이 대상 열에 설정되지 않은 경우 테이블 또는 뷰에 대한 충분한 권한이 있는 사용자는 대상 열에서 마스킹된 값과 마스킹되지 않은 값의 조합을 볼 수 있습니다. 그러므로 가장 좋은 방법은 다음과 같습니다.

  • 마스킹 정책을 열에 적용할 때 주의하십시오.

  • 마스킹 정책이 있는 열을 사용하여 쿼리를 확인한 후 사용자가 테이블과 뷰를 사용할 수 있도록 설정하십시오.

  • 소스 열의 데이터가 표시될 수 있는 추가 테이블 및 뷰(즉, 대상 열)를 결정하십시오.

  • 자세한 내용은 이 항목의 마스킹 정책이 있는 열 구하기 섹션을 참조하십시오.

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

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

정책 조건은 세션에서 사용자의 활성 기본 역할과 보조 역할을 직접 평가하거나, 매핑 테이블에서 활성 역할을 조회하거나, 정책 관리자가 정책을 작성하려는 방식에 따라 둘 다 수행할 수 있습니다. 정책에 매핑 테이블 조회가 포함된 경우 중앙 집중식 매핑 테이블을 생성하고 보호된 테이블과 동일한 데이터베이스에 매핑 테이블을 저장합니다. 이는 정책이 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 COLUMN 문으로 테이블 열에 정책을 적용하거나 ALTER VIEW 문으로 뷰 열에 정책을 적용합니다.

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

-- table
CREATE OR REPLACE TABLE user_info (ssn string masking policy ssn_mask);

-- view
CREATE OR REPLACE VIEW user_info_v (ssn masking policy ssn_mask_v) AS SELECT * FROM user_info;

Copy

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

-- table
ALTER TABLE IF EXISTS user_info MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask;

-- view
ALTER VIEW user_info_v MODIFY COLUMN ssn_number SET MASKING POLICY ssn_mask_v;

Copy

구문 및 사용법에 대한 자세한 내용은 ALTER TABLE … ALTER COLUMN 및 ALTER VIEW 뷰를 참조하십시오.

마스킹 정책에서 UDF를 사용하는 경우 이 항목의 마스킹 정책의 사용자 정의 함수 를 참조하십시오.

열에 조건부 마스킹 정책 적용하기¶

조건부 열 을 사용하여 마스킹 정책을 생성 한 후 아직은 열이 마스킹 정책으로 보호되지 않을 때 열에 조건부 마스킹 정책을 설정하는 두 가지 옵션이 있습니다.

1. 새 테이블이나 뷰의 경우, 해당 CREATE 문으로 테이블 또는 뷰 열에 정책을 적용합니다.

   구문 및 사용법에 대한 자세한 내용은 다음을 참조하십시오.

   • CREATE TABLE

   • CREATE VIEW

   • CREATE MATERIALIZED VIEW

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

   -- table
   CREATE OR REPLACE TABLE user_info (email string masking policy email_visibility) USING (email, visibility);
   
   --view
   CREATE OR REPLACE VIEW user_info_v (email masking policy email_visibility) USING (email, visibility) AS SELECT * FROM user_info;
   

   Copy

2. 기존 테이블이나 뷰의 경우, 해당 ALTER 문으로 테이블 또는 뷰 열에 정책을 설정합니다.

   구문 및 사용법에 대한 자세한 내용은 다음을 참조하십시오.

   • ALTER TABLE

   • ALTER TABLE … ALTER COLUMN

   • ALTER VIEW

   • ALTER MATERIALIZED VIEW

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

   -- table
   ALTER TABLE IF EXISTS user_info MODIFY COLUMN email
   SET MASKING POLICY email_visibility USING (EMAIL, VISIBILITY);
   
   -- VIEW
   ALTER VIEW user_info_v MODIFY COLUMN email
   SET MASKING POLICY email_visibility USING (email, visibility);
   

   Copy

열의 마스킹 정책 바꾸기¶

열에 마스킹 정책이 설정되면 전체 테이블이나 뷰를 바꿀 필요 없이 열에 대한 마스킹 정책을 다른 마스킹 정책으로 바꾸는 두 가지 서로 다른 경로가 있습니다.

다음 예에서는 ALTER TABLE 명령을 사용합니다. ALTER VIEW 명령 사용 시 뷰에도 같은 접근 방식이 적용됩니다.

• 한 문의 테이블 열에서 정책을 설정 해제한 다음, 다른 문의 열에 대해 새 정책을 설정합니다.

  ALTER TABLE t1 MODIFY COLUMN c1 UNSET MASKING POLICY;
  
  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2;
  

  Copy

• 단일 문에서 FORCE 키워드를 사용해 정책을 바꿉니다.

  ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY p2 FORCE;
  

  Copy

  참고:

  • FORCE 키워드에는 열에 현재 설정된 마스킹 정책의 데이터 타입(즉, STRING)과 일치하도록 ALTER TABLE 문(즉, STRING)에 있는 정책의 데이터 타입 이 필요합니다.

  • FORCE 키워드를 USING 절과 결합하여 열에 대한 조건부 마스킹 정책을 설정할 수 있습니다.

    ALTER TABLE t1 MODIFY COLUMN c1 SET MASKING POLICY policy1 USING (c1, c3, c4) FORCE;
    

    Copy

행 액세스 정책¶

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

이 동작은 마스킹 정책에서 조건부 열로 사용되는 열에도 적용됩니다.

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

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

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

구체화된 뷰¶

Snowflake는 구체화된 뷰 열에 마스킹 정책을 설정하는 것을 허용합니다. 쿼리 런타임 시에 쿼리 계획은 존재하는 모든 마스킹 정책을 실행한 후 구체화된 뷰 재작성을 생성합니다. 구체화된 뷰가 재작성되면 구체화된 뷰 열에 마스킹 정책을 설정할 수 없습니다.

구체화된 뷰 열에 마스킹 정책을 설정하는 두 가지 옵션이 있습니다.

1. 새 구체화된 뷰의 경우 CREATE MATERIALIZED VIEW 문을 실행합니다.

2. 기존 구체화된 뷰의 경우 구체화된 뷰에 대해 ALTER VIEW … MODIFY COLUMN 문을 실행합니다.

새 구체화된 뷰의 경우 다음 문을 실행합니다.

CREATE OR REPLACE MATERIALIZED VIEW user_info_mv
  (ssn_number masking policy ssn_mask)
AS SELECT ssn_number FROM user_info;

Copy

기존 구체화된 뷰의 경우 이 항목의 열에 마스킹 정책 적용하기 섹션에서 뷰 예제를 참조하십시오.

추가적으로 마스킹 정책 및 구체화된 뷰와 관련한 다음과 같은 두 가지 제한 사항이 있습니다.

1. 기본 테이블에서 구체화된 뷰가 이미 생성된 경우에는 테이블 열에 마스킹 정책을 설정할 수 없습니다. 이러한 시도가 수행되는 경우 Snowflake는 다음 오류 메시지를 반환합니다.

   SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
   

   Copy

2. 마스킹 정책이 기본 테이블 열에 설정되고 구체화된 뷰가 해당 테이블에서 생성되는 경우, 구체화된 뷰에는 마스킹 정책으로 보호되지 않는 열만 포함됩니다. 마스킹 정책으로 보호되는 1개 이상의 열을 포함하는 시도가 발생하면 Snowflake는 다음 오류 메시지도 반환합니다.

   Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
   

   Copy

마스킹 정책이 있는 열 구하기¶

마스킹 정책이 적용된 열의 목록을 구하려면 다음 문을 실행합니다. 자세한 내용은 POLICY_REFERENCES 섹션을 참조하십시오.

SELECT * from table(
  INFORMATION_SCHEMA.POLICY_REFERENCES(
    policy_name=>'<policy_name>'
  )
);

Copy

DESCRIBE TABLE 또는 DESCRIBE VIEW 문을 실행하여 테이블 또는 뷰의 열에 대한 마스킹 정책을 확인합니다.

오브젝트 태깅 및 마스킹 정책¶

자세한 내용은 태그 기반 마스킹 정책 섹션을 참조하십시오.

열에 직접 할당된 마스킹 정책이 태그 기반 마스킹 정책보다 우선합니다.

마스킹 정책에서의 해싱, 암호화 및 암호화 함수¶

해싱 및 암호화/체크섬 을 마스킹 정책에서 사용하여 민감한 데이터를 마스킹할 수 있습니다.

자세한 내용은 고급 열 수준 보안 항목 을 참조하십시오.

외부 테이블¶

외부 테이블 VALUE 열은 기본적으로 자동으로 생성되므로 CREATE EXTERNAL TABLE 문으로 외부 테이블 생성 할 때 이 열에 마스킹 정책을 할당할 수 없습니다.

외부 테이블에서 ALTER TABLE … ALTER COLUMN 문을 실행하여 외부 테이블 VALUE 열에 마스킹 정책을 할당할 수 있습니다. VALUE 열을 보호하는 마스킹 정책의 데이터 타입은 VARIANT이어야 합니다.

ALTER TABLE t1 MODIFY COLUMN VALUE SET MASKING POLICY p1;

Copy

다음과 같이 외부 테이블의 가상 열에 마스킹 정책을 할당할 수 있습니다.

• 외부 테이블의 VALUE 열을 보호하는 마스킹 정책에서 EXEMPT_OTHER_POLICIES 마스킹 정책 속성을 TRUE 로 설정합니다.

  이 속성이 아직 설정되지 않은 경우 VALUE 열을 보호하는 마스킹 정책에 대해 CREATE OR REPLACE 문을 실행하고 EXEMPT_OTHER_POLICIES 속성을 지정하십시오. 가상 열은 VALUE 열을 보호하는 정책을 상속하며, 이 속성을 사용하면 가상 열에 대한 정책이 상속된 정책보다 우선할 수 있습니다. 자세한 내용은 CREATE MASKING POLICY 섹션을 참조하십시오.

• ALTER TABLE 명령을 사용하여 가상 열에 다른 마스킹 정책을 할당합니다. 가상 열은 덜 민감하므로 이 정책은 VALUE 열의 정책보다 덜 엄격할 수 있습니다. 가상 열에는 VALUE 열보다 적은 양의 데이터가 포함되고 VALUE 열에는 외부 테이블의 각 행에 대한 모든 데이터가 포함됩니다.

  가상 열을 보호하는 정책의 데이터 타입은 가상 열의 데이터 타입에 따라 다릅니다.

마스킹 정책의 조건부 열에 관해, 가상 열을 조건부 열 인자로 나열하여 첫 번째 열 인자를 마스킹하거나 토큰화해야 할지 여부를 결정할 수 있습니다. 하지만 가상 열을 마스킹하거나 토큰화할 첫 번째 열로 지정할 수 없습니다.

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

스트림¶

테이블의 열에 대한 마스킹 정책은 동일한 테이블의 스트림으로 전달됩니다.

그 결과 권한이 없는 사용자가 마스킹된 데이터를 볼 수 있으며, 승인된 사용자가 생성한 스트림은 마스킹 정책에 정의된 대로 데이터를 표시합니다.

복제된 오브젝트¶

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

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

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

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

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

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

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

CREATE TABLE … AS SELECT(CTAS) 문¶

CREATE TABLE … AS SELECT(CTAS) 문을 실행하면 문에 포함된 열에 마스킹 정책이 적용된 후에 새 테이블에 데이터가 채워집니다(즉, 해당 열 데이터가 새 테이블에서 마스킹됨). CTAS 문을 사용하여 생성된 테이블은 소스 오브젝트와 열 세트가 다를 수 있고 Snowflake는 새 테이블 열에 마스킹 정책을 암시적으로 적용할 수 없기 때문에 이러한 흐름이 준수됩니다.

마스킹되지 않은 데이터를 복사해야 하는 경우에는 보호된 데이터에 대한 권한이 있는 역할을 사용하여 CTAS 문을 실행합니다. 새 테이블을 생성한 후 새 테이블의 소유권을 다른 역할로 이전하고 마스킹 정책 관리자에게 새 테이블의 열에 마스킹 정책을 적용하도록 요청하십시오.

자세한 내용은 CREATE TABLE 섹션을 참조하십시오.

집계 함수 및 마스킹된 열을 사용한 쿼리¶

마스킹된 데이터가 포함된 열에 집계 함수 를 사용할 수 있습니다.

대표적인 사용 사례는 데이터 분석가가 실제 데이터를 볼 필요 없이 소셜 시큐리티 번호 열에 대한 COUNT 를 구하는 것입니다. 그러나 데이터 분석가가 SELECT 를 사용하여 마스킹된 테이블 열에 대한 쿼리를 실행하는 경우 쿼리는 고정 마스킹 값을 반환합니다. 현재 세션에서 PAYROLL 사용자 지정 역할이 있는 사용자는 마스킹되지 않은 데이터를 보고 다른 모든 사용자는 마스킹된 데이터를 봅니다.

이러한 결과를 얻으려면:

1. 테이블 소유자가 집계 함수가 포함된 열에 대한 뷰를 생성합니다.

   CREATE VIEW ssn_count AS SELECT DISTINCT(ssn) FROM table1;
   

   Copy

2. ANALYST 역할에 뷰에 대한 모든 권한을 부여합니다. 분석가에게 테이블에 대한 권한은 부여하지 않아야 합니다.

3. 테이블 열에 마스킹 정책을 적용합니다. 뷰 열에 대한 정책이 있는 경우에는 테이블 정책이 항상 뷰 정책보다 먼저 적용된다는 점에 유의하십시오.

   CASE
     WHEN CURRENT_ROLE() IN ('PAYROLL') THEN val
     ELSE '***MASKED***'
   END;
   

   Copy

4. 뷰 열에서 쿼리를 실행합니다.

   USE ROLE analyst;
   SELECT COUNT(DISTINCT ssn) FROM v1;
   

   Copy

마스킹 정책의 사용자 정의 함수¶

UDF 를 마스킹 정책 조건으로 전달할 수 있습니다.

테이블 또는 뷰 열의 데이터 타입 UDF와 마스킹 정책이 일치하도록 하는 것이 중요합니다. 데이터 타입이 VARIANT인 테이블 열과 UDF를 갖는 것과 같이 데이터 타입이 서로 다르고 마스킹 정책(정책 조건에 이 UDF가 있음)이 VARCHAR 데이터 타입을 반환하는 경우, Snowflake는 이 마스킹 정책이 테이블 열에 설정될 때 이 테이블 열에서 쿼리를 만들 경우 오류를 반환합니다.

테이블 열, UDF, 마스킹 정책의 데이터 타입을 일치시키는 대표적인 예는 CREATE MASKING POLICY 에서 JSON(베리언트)에서 JavaScript UDF 사용하기 예를 참조하십시오.

데이터 공유¶

사용법:

• 공급자가 공유 테이블 또는 뷰에 정책을 할당하고 정책 조건이 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는 다음과 같은 경우에 오류를 반환합니다.

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

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

복제¶

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

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

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

• 기본 데이터베이스에 포함된 테이블 또는 뷰에 다른 데이터베이스의 마스킹 정책에 대한 현수 참조 가 있습니다.

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

참고

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

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

쿼리 프로필¶

마스킹 정책이 있는 열에서 사용되는 경우, EXPLAIN 명령의 출력에는 마스킹 정책의 본문이 아닌 마스킹된 데이터가 포함됩니다.

다음 예에서는 직원 식별 번호 및 소셜 시큐리티 번호 테이블에서 쿼리에 대한 EXPLAIN 계획을 생성합니다. 이 예에서 명령은 JSON 형식의 예를 생성합니다.

소셜 시큐리티 번호가 포함된 열에는 마스킹 정책이 있습니다.

EXPLAIN USING JSON SELECT * FROM mydb.public.ssn_record;

{
  "GlobalStats": {
    "partitionsTotal": 0,
    "partitionsAssigned": 0,
    "bytesAssigned": 0
  },
  "Operations": [
    [
      {
        "id": 0,
        "operation": "Result",
        "expressions": [
          "1",
          "'**MASKED**'"
        ]
      },
      {
        "id": 1,
        "parent": 0,
        "operation": "Generator",
        "expressions": [
          "1"
        ]
      }
    ]
  ]
}

데이터 언로드하기¶

마스킹 정책이 있는 열에 대해 COPY INTO <위치> 명령을 사용하면 마스킹 정책이 데이터에 적용됩니다. 그러므로 명령을 실행한 후 권한이 없는 사용자는 마스킹된 데이터를 보게 됩니다.

Snowflake Native App Framework¶

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

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

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

• 차단된 컨텍스트 함수.

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

Dynamic Data Masking 및 External Tokenization 정책을 효과적으로 관리하기 위해서는, 열의 데이터를 마스킹하는 방식이 중앙 집중식 보안 방식, 분산형 방식 또는 이러한 각 두 방식의 하이브리드 방식을 따라야 하는지 고려하는 것이 좋습니다.

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

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

마스킹 정책 권한¶

이 섹션에서는 Column-level Security 마스킹 정책 권한 및 이러한 권한이 중앙 집중식, 분산형 또는 하이브리드 관리 방식에 적용되는 방법을 설명합니다.

Column-level Security 마스킹 정책을 위해 Snowflake가 제공하는 권한은 다음과 같습니다.

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

다음 예에서는 권한 부여가 다른 관리 방식에 적용되는 방법을 보여줍니다. 역할에 APPLY 권한을 부여한 후 ALTER TABLE … ALTER COLUMN 문을 사용하여 테이블 열에 마스킹 정책을 설정하거나 ALTER VIEW 문을 사용하여 뷰 열에 설정할 수 있습니다(마스킹 정책에 대한 APPLY 권한이 있는 역할의 구성원이 이 작업을 수행).

중앙 집중식 관리

중앙 집중식 관리 방식에서는 보안 담당자 사용자 지정 역할(예: security_officer)만 마스킹 정책을 생성하고 테이블 또는 뷰의 열에 적용할 수 있습니다. 이 방식은 마스킹 정책 관리 및 민감한 데이터의 마스킹 측면에서 가장 우수한 일관성을 제공할 수 있습니다.

-- create a security_officer custom role

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;

-- grant CREATE AND APPLY masking policy privileges to the SECURITY_OFFICER custom role.

GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

GRANT APPLY MASKING POLICY ON ACCOUNT TO ROLE security_officer;

Copy

여기서:

• schema_name

  스키마에 대한 식별자를 지정하며, 이는 스키마가 생성된 데이터베이스에 대해 고유한 식별자여야 합니다.

  또한, 식별자는 알파벳 문자로 시작해야 하며 전체 식별자 문자열을 큰따옴표(예: “My object”)로 묶지 않는 한 공백이나 특수 문자를 포함할 수 없습니다. 큰따옴표로 묶인 식별자도 대/소문자를 구분합니다.

  자세한 내용은 식별자 요구 사항 섹션을 참조하십시오.

하이브리드 관리

하이브리드 관리 방식에서는 보안 담당자 사용자 지정 역할(예: security_officer)이 마스킹 정책을 생성하고 개별 팀(예: 재무, 급여, 인사)은 마스킹 정책을 팀이 소유한 테이블 또는 뷰의 열에 적용합니다. 이 방식을 사용하면 일관된 정책 생성 및 유지 관리를 활용할 수 있지만, 민감한 데이터를 마스킹하는 것과 관련한 개별 팀의 책임이 증가합니다.

USE ROLE ACCOUNTADMIN;
CREATE ROLE security_officer;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE security_officer;

Copy

SECURITY_OFFICER 사용자 지정 역할은 HUMAN_RESOURCES 사용자 지정 역할이 소유한 오브젝트의 열에서 소셜 시큐리티 번호(즉, 마스킹 정책: ssn_mask)를 마스킹할 수 있는 APPLY 권한을 인사 팀(즉, HUMAN_RESOURCES 사용자 지정 역할이 있는 사용자)에게 부여합니다.

USE ROLE security_officer;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

여기서:

• grant apply on masking policy policy_name to role role_name;

  정책 소유자가 열에 대한 지정된 마스킹 정책의 설정 해제 및 설정 작업을 오브젝트 소유자에게 분산하기 위해 사용됩니다.

  이 권한은 오브젝트 소유자도 데이터 관리자로 간주되는 임의 액세스 제어 를 지원합니다.

분산형 방식

분산형 관리 방식에서는 개별 팀이 마스킹 정책을 생성하고 테이블 또는 뷰의 열에 적용합니다. 이 방식은 개별 팀이 마스킹 정책 관리 및 민감한 데이터 마스킹에 대한 모든 책임을 지기 때문에, 민감한 데이터가 올바르게 마스킹되지 않고 일관적인 정책 관리가 수행되지 않을 수 있습니다.

이 대표적인 예에서는 지원 팀(사용자 지정 역할 SUPPORT가 있는 사용자) 및 재무 팀(사용자 지정 역할 FINANCE가 있는 사용자)가 마스킹 정책을 생성할 수 있습니다. 이러한 사용자 지정 역할에는 SECURITY_OFFICER 사용자 지정 역할이 포함되지 않을 수 있다는 점에 유의하십시오.

USE ROLE ACCOUNTADMIN;
GRANT CREATE MASKING POLICY ON SCHEMA mydb.mysch TO ROLE support;
GRANT CREATE MASKING POLICY ON SCHEMA <DB_NAME.SCHEMA_NAME> TO ROLE FINANCE;

Copy

지원 팀은 HUMAN_RESOURCES 사용자 지정 역할이 소유한 오브젝트의 열에서 소셜 시큐리티 번호(즉, 마스킹 정책: ssn_mask)를 마스킹할 수 있는 APPLY 권한을 인사 팀(즉, HUMAN_RESOURCES 사용자 지정 역할이 있는 사용자)에게 부여합니다.

USE ROLE support;
GRANT APPLY ON MASKING POLICY ssn_mask TO ROLE human_resources;

Copy

재무 팀은 AUDIT_INTERNAL 사용자 지정 역할이 소유한 오브젝트의 열에서 현금 흐름 데이터(즉, 마스킹 정책: cash_flow_mask)를 마스킹할 수 있는 APPLY 권한을 감사 팀(즉, AUDIT_INTERNAL 사용자 지정 역할이 있는 사용자)에게 부여합니다.

USE ROLE finance;
GRANT APPLY ON MASKING POLICY cash_flow_mask TO ROLE audit_internal;

Copy

마스킹 정책 권한에 대한 자세한 내용은 다음을 참조하십시오.

• Dynamic Data Masking 사용하기

• External Tokenization 사용하기

마스킹 정책 DDL¶

Column-level Security 마스킹 정책을 관리하기 위해 Snowflake가 제공하는 명령 세트는 다음과 같습니다.

• CREATE MASKING POLICY

• ALTER MASKING POLICY (참고 항목: ALTER TABLE, ALTER TABLE … ALTER COLUMN, ALTER VIEW)

• DROP MASKING POLICY

• SHOW MASKING POLICIES

• DESCRIBE MASKING POLICY

다음 테이블은 Column-level Security 마스킹 정책 DDL 작업과 필요한 권한 사이의 관계를 요약하여 제공합니다.

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

마스킹 정책 살펴보기¶

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

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.MASKING_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(
      'my_table',
      'table'
    )
  );
  

  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 탭이 열립니다. 필요에 따라 태그 및 정책 할당을 편집할 수 있습니다.

추가적인 세부 사항은 태그 및 정책 검색 섹션을 참조하십시오.