Column-level Security 이해하기

이 항목에서는 Column-level Security의 일반적인 개요를 제공하고 Dynamic Data Masking 및 External Tokenization 모두에 공통적인 기능과 지원에 대한 설명을 제공합니다.

태그와 함께 마스킹 정책을 사용하는 방법에 대해 자세히 알아보려면 태그 기반 마스킹 정책 섹션을 참조하십시오.

Column-level Security란 무엇입니까?

Snowflake의 Column-level Security를 사용하면 테이블 또는 뷰 내의 열에 마스킹 정책을 적용할 수 있습니다. 현재 열 수준 보안에는 다음의 두 가지 기능이 포함됩니다.

  1. 동적 데이터 마스킹

  2. 외부 토큰화

동적 데이터 마스킹은 쿼리 시간에 테이블 및 뷰 열에 있는 일반 텍스트 데이터를 선별적으로 마스킹하는 마스킹 정책을 사용하는 열 수준 보안 기능입니다.

External Tokenization을 사용하면 계정은 데이터를 토큰화한 후 Snowflake에 로드하고 쿼리 런타임 시에 데이터의 토큰화를 해제할 수 있습니다. 토큰화는 민감한 데이터의 암호를 해독할 수 없는 토큰으로 대체하여 해당 데이터를 제거하는 프로세스입니다. External Tokenization은 외부 함수 와 함께 마스킹 정책을 사용합니다.

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

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

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

The masking policy admin can apply masking policies to tables and views.

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

Masking policy results for authorized and unauthorized roles.

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

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

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

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

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

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

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

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

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

마스킹 정책은 어떻게 작동합니까?

Dynamic Data Masking 및 External Tokenization을 위한 마스킹 정책은 유의해야 할 한 가지 예외(External Tokenization을 위한 마스킹 정책의 경우 마스킹 정책 본문에 외부 함수 를 사용해야 함)를 제외하고 구조와 형식이 동일합니다.

외부 토큰화의 경우 Snowflake에 데이터를 로드하기 전에 데이터를 토큰화하기 위해 서드 파티 토큰화 공급자가 필요하기 때문에 이러한 예외가 적용됩니다. 쿼리 런타임 시에 Snowflake는 외부 함수를 사용하여 토큰화 공급자를 대상으로 REST API 호출을 수행한 후, 토큰화 정책(Snowflake 외부에서 생성된)을 평가하여 마스킹 정책 조건에 따라 토큰화된 데이터 또는 토큰화가 해제된 데이터를 반환합니다. 지정된 쿼리에서 올바른 데이터가 반환될 수 있도록 하려면 Snowflake와 토큰화 공급자에서 역할이 매핑되어야 한다는 점에 유의하십시오.

Snowflake는 CREATE MASKING POLICY 를 사용한 마스킹 정책 생성을 지원합니다. 예:

-- 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;

여기서:

employee_ssn_mask

Dynamic Data Masking 정책의 이름입니다.

employee_ssn_detokenize

External Tokenization 정책의 이름입니다.

as (val string) returns string

입력 및 출력 데이터 타입을 지정합니다. 데이터 타입은 일치해야 합니다.

->

정책 서명과 본문을 분리합니다.

case ... end;

마스킹 정책 본문(즉, SQL 식) 조건을 지정합니다.

이러한 두 예에서 쿼리 연산자가 현재 세션에서 PAYROLL 사용자 지정 역할을 사용하는 경우 연산자에는 마스크/토큰이 해제된 값이 표시됩니다. 그렇지 않으면, 고정 마스킹/토큰화된 값이 표시됩니다.

ssn_unprotect

토큰화된 데이터에서 작업을 수행하는 외부 함수입니다.

기존 마스킹 정책을 업데이트하고 정책의 현재 정의를 확인해야 할 경우 GET_DDL 함수를 호출하거나 DESCRIBE MASKING POLICY 명령을 실행합니다.

그런 다음, ALTER MASKING POLICY 명령으로 마스킹 정책 정의를 업데이트할 수 있습니다. 마스킹 정책이 열에 설정된 경우 이 명령이 열에서 마스킹 정책을 설정 해제할 필요는 없습니다. 따라서 정책으로 보호되는 열은 정책 정의가 업데이트되는 동안 보호된 상태로 유지됩니다.

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

조건부 열 사용

조건부 마스킹은 마스킹 정책을 사용하여 하나 이상의 다른 열에 있는 값을 기반으로 테이블이나 뷰의 열 데이터를 선택적으로 보호합니다.

다른 열을 사용하여 주어진 열의 데이터를 보호해야 할지 여부를 결정하면 정책 관리자(즉, POLICY_ADMIN 사용자 지정 역할을 가진 사용자)가 더 자유롭게 정책 조건을 만들 수 있습니다.

두 가지 대표적인 정책 예의 차이점에 유의하십시오.

마스킹 정책

동적 데이터 마스킹에 이 정책을 사용할 수 있습니다.

create masking policy email_mask as
(val string) returns string ->
  case
    when current_role() in ('PAYROLL') then val
    else '******'
  end;

이 정책에서는 문자열 데이터가 포함된 열을 나타내는 단 하나의 인자 val 을 지정합니다. 이 정책은 한 번만 만들면 문자열 데이터가 포함된 모든 열에 적용할 수 있습니다. CURRENT_ROLEPAYROLL 사용자 지정 역할인 사용자만 열 데이터를 볼 수 있습니다. 그렇지 않으면, Snowflake는 쿼리 결과에 고정된 마스킹된 값을 반환합니다.

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

조건부 마스킹 정책

이 예의 인자 (email varchar, visibility string) 에 유의하십시오.

create masking policy email_visibility as
(email varchar, visibility string) returns varchar ->
  case
    when current_role() = 'ADMIN' then email
    when visibility = 'Public' then email
    else '***MASKED***'
  end;

이 정책에서는 두 개의 인자 emailvisibility 를 지정하는데, 이들 인자는 열 이름입니다. 첫 번째 열은 항상 마스킹할 열을 지정합니다. 두 번째 열은 첫 번째 열을 마스킹할지 여부를 평가하는 조건부 열입니다. 여러 조건부 열을 지정할 수 있습니다. 이 정책에서는 CURRENT_ROLE 이 ADMIN 사용자 지정 역할인 사용자가 이메일 주소를 볼 수 있습니다. 이메일 주소에 가시성 열 값인 Public 도 있는 경우에는 이메일 주소가 쿼리 결과에 표시됩니다. 그렇지 않으면, Snowflake는 이메일 열에 대해 고정된 마스킹 값을 포함한 쿼리 결과를 반환합니다.

테이블 또는 뷰의 열 구조가 정책에 지정된 열과 일치하는 경우 이 정책을 여러 테이블과 뷰에 사용할 수 있습니다. 자세한 내용은 CREATE MASKING POLICY 섹션을 참조하십시오.

각각의 대표적인 예에 같은 오브젝트 타입이 사용되므로, 다음과 같은 것을 포함하여 정책의 전체 동작이 유사해야 합니다.

  • 쿼리 런타임 평가.

  • 유틸리티(예: 컨텍스트 함수 를 사용해 민감한 데이터 보호).

  • 권한 구조.

  • SoD(직무 분리)를 지원하는 다양한 관리 접근 방식과 함께 사용.

제한 사항

기존 마스킹 정책 제한 외에, 조건부 마스킹 정책에는 다음과 같은 제한 사항이 있습니다.

  • 가상 열. 자세한 내용은 이 항목의 외부 테이블 을 참조하십시오.

  • 행 액세스 정책. 자세한 내용은 이 항목의 행 액세스 정책 을 참조하십시오.

  • 외부 테이블. 자세한 내용은 이 항목의 외부 테이블 섹션을 참조하십시오.

고려 사항

기존의 일반 마스킹 정책 고려 사항 외에도, 조건부 마스킹 정책을 사용하기 전에 다음 사항을 평가하십시오.

  • CREATE MASKING POLICY 문에 지정된 모든 열이 같은 테이블 또는 뷰에 있는지 확인합니다.

  • 정책 정의에서 열 인자의 수를 최소화합니다. Snowflake는 쿼리 런타임에 각 열을 평가해야 합니다. 지정하는 열 수를 줄이면 전체적인 성능이 더 빨라집니다.

  • Information Schema 테이블 함수 POLICY_REFERENCES 를 호출하여 마스킹 정책에서 조건부 열 사용을 추적합니다.

조건부 열을 사용하여 마스킹 정책을 설정하는 자세한 방법은 이 항목의 열에 조건부 마스킹 정책 적용하기 를 참조하십시오.

쿼리 런타임 시점의 마스킹 정책

런타임 시점에 Snowflake는 마스킹 정책에 지정된 열에 마스킹 정책 식을 적용하도록 쿼리를 다시 작성합니다. 마스킹 정책은 SQL 식에서 열이 참조되는 위치에 관계없이 열에 적용됩니다.

  • 프로젝션.

  • JOIN 조건자.

  • WHERE 절 조건자.

  • ORDER BY 및 GROUP BY 절.

중요

마스킹 정책은 SQL 구문이 관련 열을 참조하는 모든 위치에 의도적으로 적용되어 마스킹된 열 데이터가 포함된 창의적인 쿼리를 통한 데이터의 익명화를 방지합니다.

그러므로 쿼리를 실행하여 1개 이상의 열에 마스킹된 데이터가 있는 경우 마스킹된 데이터로 인해 필요한 컨텍스트에서 모든 쿼리 출력 데이터를 평가할 수 없기 때문에 쿼리 출력에서 예상 값이 제공되지 않을 수 있습니다.

중첩된 오브젝트를 사용한 마스킹 정책:

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

  1. 테이블에 적용되는 마스킹 정책이 항상 먼저 실행됩니다.

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

  3. 중첩 뷰가 있는 경우(예: table_1 » view_1 » view_2 » … view_n), 왼쪽에서 오른쪽으로 순차적으로 정책이 적용됩니다.

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

Masking policies with tables and views.

사용자 쿼리:

다음 예에서는 사용자 제출 쿼리 이후의 마스킹 정책(즉, sql_expression)을 email 열에만 적용하는 Snowflake 런타임 쿼리 재작성을 보여줍니다.

SELECT email, city
from customers
where city = 'San Mateo';

SELECT <SQL_expression>(email), city
from customers
where city = 'San Mateo';

WHERE 절 조건자에 보호된 열이 포함된 쿼리(안티 패턴):

다음 예에서는 사용자 제출 쿼리 이후의 마스킹 정책(즉, sql_expression)이 비교의 한 쪽에만 적용(예: 이메일 열, 이메일 열과 비교되는 문자열 제외)되는 Snowflake 런타임 쿼리 재작성을 보여줍니다. 쿼리 결과는 사용자가 의도한 결과가 아닙니다. 비교의 한 쪽만 마스킹하는 것은 일반적인 안티 패턴입니다.

SELECT email
from customers
where email = 'user@example.com';

SELECT <SQL_expression>(email)
from customers
where <SQL_expression>(email) = 'user@example.com';

JOIN 조건자에 보호된 열이 포함된 쿼리(안티 패턴):

select b.email, d.city
from
  sf_tuts.public.emp_basic as b
  join sf_tuts.public.emp_details as d on b.email = d.email;

select
  <SQL_expression>(b.email),
  d.city
from
  sf_tuts.public.emp_basic as b
  join sf_tuts.public.emp_details as d on <SQL_expression>(b.email) = <SQL_expression>(d.email);

쿼리 런타임 고려 사항

Snowflake는 열에 마스킹 정책을 적용하는 효과와 쿼리 연산자가 마스킹된 데이터를 볼 수 있는지 여부를 예상할 때 다음 요소를 고려할 것을 권장합니다.

현재 세션

CURRENT_ROLE 을 사용한 마스킹 정책 조건.

실행 중 역할

INVOKER_ROLE 을 사용한 마스킹 정책 조건.

역할 계층 구조

IS_ROLE_IN_SESSION 또는 IS_GRANTED_TO_INVOKER_ROLE 을 사용한 마스킹 정책 조건.

데이터 공유

Snowflake Secure Data Sharing 를 사용한 데이터 공유 여부. 이 항목의 제한 사항 을 참조하십시오.

복제

이 항목의 복제 섹션을 참조하십시오.

하위 쿼리

마스킹 정책은 정책 정의의 하위 쿼리를 참조할 수 있지만, Snowflake가 제공하는 하위 쿼리 지원에는 제한이 있습니다. 자세한 내용은 하위 쿼리 관련 작업하기 섹션을 참조하십시오.

마스킹 정책의 UDF

열의 데이터 타입 UDF와 마스킹 정책이 일치하는지 확인합니다. 자세한 내용은 이 항목의 마스킹 정책의 사용자 정의 함수 섹션을 참조하십시오.

검색 최적화 서비스

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

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

처음 세 항목에 대해서는 고급 Column-level Security 항목 에서 자세한 설명이 제공됩니다. 공유 상황에서는 외부 함수를 호출할 수 없기 때문에 데이터 공유는 Dynamic Data Masking에만 적용됩니다.

궁극적으로는 구체적인 사용 사례에 따라 Dynamic Data Masking 또는 External Tokenization 중 가장 적합한 기능이 결정됩니다.

Dynamic Data Masking 또는 External Tokenization 선택하기

조직의 요구 사항을 최적으로 충족하는 올바른 기능을 선택하려면 관련 고려 사항 및 제한 사항과 함께 데이터의 주요 사용 사례를 평가해야 합니다. 다음 두 섹션에서는 두 기능 사이에서의 이점과 제한 사항을 요약하여 제공합니다.

이점

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

요소

동적 데이터 마스킹

외부 토큰화

참고

비식별화 이후에 분석 가치가 보존됩니다.

토큰화는 지정된 문자 세트에 대한 고유 값을 제공하므로, 민감한 정보를 공개하지 않고 토큰화된 값으로 레코드를 그룹화할 수 있습니다.

예를 들어, 환자 진단 코드를 토큰화하여 진단 코드별로 의료 레코드를 그룹화할 수 있습니다. 그러면 데이터 분석자는 진단 코드에 대한 뷰를 쿼리하여 고유 진단 코드가 있는 환자의 수를 구할 수 있습니다.

토큰화된 데이터를 사전에 로드합니다.

권한이 없는 사용자는 절대로 실제 데이터 값을 볼 수 없습니다. 서드 파티 토큰화 공급자가 필요합니다.

마스킹되지 않은 데이터를 사전에 로드합니다.

기본 제공 Snowflake 기능만 필요하고 서드 파티 기능은 필요하지 않습니다.

데이터 공유.

자세한 내용은 이 항목의 공유 테이블 및 뷰가 포함된 마스킹 정책 섹션을 참조하십시오.

사용 편의성 및 변경 관리.

정책을 한 번 작성하고 데이터베이스와 스키마 전체에서 수천 개의 열에 적용할 수 있습니다.

데이터 관리 및 SoD.

보안 또는 개인정보보호 담당자는 오브젝트 소유자가 아닌 보호할 열을 결정합니다.

마스킹 정책은 관리가 쉽고 중앙 집중식 및 분산형 관리 모델을 지원합니다.

데이터 인증 및 거버넌스.

역할 또는 사용자 지정 권한에 따라 컨텍스트 데이터에 액세스합니다.

보안 또는 개인정보보호 담당자가 구현한 데이터 거버넌스를 지원하며, ACCOUNTADMIN 또는 SECURITYADMIN 시스템 역할의 권한이 부여된 사용자가 불필요하게 데이터를 보는 것을 방지할 수 있습니다.

데이터베이스 복제 및 계정 오브젝트 복제.

이 항목의 복제 섹션을 참조하십시오.

제한 사항

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

제한 사항

동적 데이터 마스킹

외부 토큰화

참고

공유 오브젝트.

자세한 내용은 이 항목의 공유 테이블 및 뷰가 포함된 마스킹 정책 섹션을 참조하십시오.

구체화된 뷰(MV).

전체 요약은 이 항목의 구체화된 뷰 를 참조하십시오.

DROP MASKING POLICY

정책을 삭제하기 전, ALTER TABLE … ALTER COLUMN 또는 ALTER VIEW 를 사용하여 테이블 또는 뷰 열에서 정책의 설정을 해제하십시오.

DROP DATABASEDROP SCHEMA

데이터베이스 또는 스키마를 삭제하려면 마스킹 정책 및 해당 매핑이 데이터베이스 또는 스키마 내에 자체적으로 포함되어야 합니다.

예를 들어, database_1policy_1 을 포함하고 policy_1database_1 에서만 사용됩니다.

가상 열.

마스킹 정책은 가상 열에 적용할 수 없습니다. 소스 테이블 열 또는 뷰 열에 정책을 적용하십시오.

외부 테이블.

열 값을 마스킹해야 하는지 여부를 판단하기 위한 조회 테이블(즉, 하위 쿼리에서)로 외부 테이블을 참조할 수 없습니다. 자세한 내용은 이 항목의 외부 테이블 섹션을 참조하십시오.

정책 정의의 입력 및 출력에서 서로 다른 데이터 타입.

마스킹 정책 정의는 입력 및 출력에서 데이터 타입이 동일해야 합니다. 즉, 대표적인 예로 입력 데이터 타입을 타임스탬프로 정의한 경우 문자열을 반환할 수 없습니다.

마스킹 정책 변경 관리.

선택한 버전 제어 시스템에서 마스킹 정책 변경 사항을 선택적으로 저장 및 추적할 수 있습니다.

향후 권한 부여.

마스킹 정책에 대한 향후 권한 부여 는 지원되지 않습니다.

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

고려 사항

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

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

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

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

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

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

테이블 및 뷰에서 Column-level Security 사용하기

Snowflake는 테이블 및 뷰가 포함된 마스킹 정책을 지원합니다. 다음은 마스킹 정책이 Snowflake의 테이블 및 뷰에 영향을 주는 방법을 설명합니다.

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

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

정책 조건은 세션에서 사용자의 활성 기본 역할과 보조 역할을 직접 평가하거나, 매핑 테이블에서 활성 역할을 조회하거나, 정책 관리자가 정책을 작성하려는 방식에 따라 둘 다 수행할 수 있습니다.

이러한 사용 사례의 경우, IS_ROLE_IN_SESSION 컨텍스트 함수를 호출하는 정책 조건을 작성하는 것이 좋습니다. 정책 예제는 IS_ROLE_IN_SESSION 함수의 섹션을 참조하십시오.

컨텍스트 함수와 마스킹 정책을 사용하는 추가 예제는 고급 Column-level Security 항목 섹션을 참조하십시오.

마스킹 정책을 열에 적용하기

열이 마스킹 정책으로 보호되지 않는 경우 테이블 또는 뷰의 열에 마스킹 정책을 적용하는 두 가지 옵션이 있습니다.

  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;

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

-- 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;

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

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

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

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

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

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

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

    -- 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;
    
  2. 기존 테이블이나 뷰의 경우, 해당 ALTER 문으로 테이블 또는 뷰 열에 정책을 설정합니다.

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

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

    -- 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);
    

열의 마스킹 정책 바꾸기

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

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

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

    alter table t1 modify column c1 unset masking policy;
    
    alter table t1 modify column c1 set masking policy p2;
    
  • 단일 문에서 FORCE 키워드를 사용해 정책을 바꿉니다.

    alter table t1 modify column c1 set masking policy p2 force;
    

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

alter table t1 modify column c1 set masking policy policy1 using (c1, c3, c4) force;

중요

열에 대한 마스킹 정책을 바꿀 때는 주의하십시오.

바꾸는 시점과 열에 대한 쿼리에 따라 두 개의 개별 문에서 정책을 바꾸도록 선택하면 UNSET 작업과 SET 작업 사이의 시간 간격에서 열 데이터가 보호되지 않으므로 데이터 누수로 이어질 수 있습니다.

하지만 대체 정책에서 정책 조건이 다른 경우 FORCE 키워드를 지정하면 (이전에는) 사용자가 데이터에 액세스할 수 있었고 정책을 바꾸면 더 이상 액세스할 수 없으므로 액세스 권한 부족으로 이어질 수 있습니다.

정책을 바꾸기 전에 내부 데이터 관리자와 상의하여 마스킹 정책으로 데이터를 보호하고 필요에 따라 마스킹 정책을 바꾸기 위한 최선의 접근 방식을 조정합니다.

행 액세스 정책

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

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

자세한 내용은 CREATE MASKING POLICYCREATE 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;

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

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

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

    SQL execution error: One or more materialized views exist on the table. number of mvs=<number>, table name=<table_name>.
    
  2. 마스킹 정책이 기본 테이블 열에 설정되고 구체화된 뷰가 해당 테이블에서 생성되는 경우, 구체화된 뷰에는 마스킹 정책으로 보호되지 않는 열만 포함됩니다. 마스킹 정책으로 보호되는 1개 이상의 열을 포함하는 시도가 발생하면 Snowflake는 다음 오류 메시지도 반환합니다.

    Unsupported feature 'CREATE ON MASKING POLICY COLUMN'.
    

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

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

SELECT * from table(information_schema.policy_references(policy_name=>'<policy_name>'));

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

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

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

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

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

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

자세한 내용은 고급 Column-level Security 항목 을 참조하십시오.

외부 테이블

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

외부 테이블에서 VALUE 문을 실행하여 외부 테이블 ALTER TABLE … ALTER COLUMN 열에 마스킹 정책을 적용할 수 있습니다.

ALTER TABLE <name> MODIFY COLUMN VALUE SET MASKING POLICY <policy_name> ;

다른 외부 테이블 열에는 정책을 설정할 수 없으며, 여기에는 사용자가 추가한 가상 열이 포함됩니다. 이러한 열을 보호해야 하는 경우 외부 테이블에 뷰를 생성한 후 뷰의 열에 정책을 적용합니다.

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

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

중요

Snowflake는 마스킹 정책에서 외부 테이블을 조회 테이블(즉, 하위 쿼리)로 사용하는 기능을 지원하지 않습니다. 데이터베이스를 복제하는 동안 Snowflake는 마스킹 정책을 복제하지만 외부 테이블은 복제하지 않습니다. 그러므로 복제된 데이터베이스의 정책은 복제된 데이터베이스에 없는 테이블을 참조하게 됩니다.

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

스트림

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

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

복제된 오브젝트

다음 방식은 복제된 오브젝트에 액세스할 때 테이블이나 뷰에 대한 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;
    
  2. ANALYST 역할에 뷰에 대한 모든 권한을 부여합니다. 분석가에게 테이블에 대한 권한은 부여하지 않아야 합니다.

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

    case
      when current_role() in ('PAYROLL') then val
      else '***MASKED***'
    end;
    
  4. 뷰 열에서 쿼리를 실행합니다.

    use role ANALYST;
    select count(DISTINCT SSN) from <view>;
    

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

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

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

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

공유 테이블 및 뷰가 포함된 마스킹 정책

사용법
  • 공유 테이블 또는 뷰에 할당된 마스킹 정책이 CURRENT_ROLE 또는 CURRENT_USER 함수를 호출하거나 보안 UDF 를 호출하는 경우 Snowflake는 NULL 값을 반환합니다.

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

  • 공유 뷰와 마스킹 정책이 서로 다른 데이터베이스에 존재할 때는 마스킹 정책이 포함된 데이터베이스에 대한 REFERENCE_USAGE 권한을 공유에 부여합니다. 자세한 내용은 여러 데이터베이스에서 데이터 공유하기 섹션을 참조하십시오.

제한 사항
  • 외부 함수:

    Dynamic Data Masking을 사용할 때 테이블 또는 뷰 열의 마스킹 정책이 외부 함수를 참조하면 테이블이나 뷰를 공유할 수 없습니다. 또한 Snowflake는 다음과 같은 경우에 오류를 반환합니다.

    • 공유 테이블이나 뷰 열에 할당된 정책이 외부 함수를 호출하는 ALTER MASKING POLICY 문으로 업데이트되는 경우.

    • 정책이 외부 함수를 호출하고 ALTER TABLE … ALTER COLUMN 문을 사용하여 정책을 공유 테이블 열에 할당하거나 ALTER VIEW 문을 사용하여 뷰 열에 정책을 할당하는 경우.

    외부 토큰화, Secure Data Sharing 은 공유의 컨텍스트에서 외부 함수를 호출할 수 없기 때문에 적용할 수 없습니다.

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

  • 데이터 공유 컨슈머는 공유 데이터베이스 또는 테이블에 마스킹 정책을 적용할 수 없습니다. 이를 해결하려면 공유 데이터베이스 또는 테이블을 가져와 해당 공유 테이블 열의 로컬 뷰에 마스킹 정책을 적용해야 합니다.

복제

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

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

  • 기본 데이터베이스가 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 <위치> 명령을 사용하면 마스킹 정책이 데이터에 적용됩니다. 그러므로 명령을 실행한 후 권한이 없는 사용자는 마스킹된 데이터를 보게 됩니다.

Column-level Security 관리하기

이 섹션에서는 마스킹 정책에 대한 전반적인 관리 방식을 결정하는 데 유용한 정보를 제공하고, Column-level Security를 관리하기 위해 필요한 권한을 설명하며, 지원되는 DDL 명령을 제공합니다.

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

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

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

정책 동작

중앙 집중식 관리

하이브리드 관리

분산형 관리

정책 만들기

보안 담당자

보안 담당자

개별 팀

열에 정책 적용

보안 담당자

개별 팀

개별 팀

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

마스킹 정책 권한

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

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

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

권한

사용법

CREATE

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

APPLY

열에서 마스킹 정책 에 대한 설정 해제 및 설정 작업을 실행할 수 있습니다.

전역 APPLY MASKING POLICY 권한(즉, ACCOUNT의 APPLY MASKING POLICY)을 부여하면 테이블과 뷰에서 DESCRIBE 작업을 실행할 수 있습니다.

구문 예제는 마스킹 정책 권한 섹션을 참조하십시오.

OWNERSHIP

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

참고

또한, 마스킹 정책 관련 작업을 수행하려면 상위 데이터베이스 및 스키마에 대한 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 <db_name.schema_name> to role security_officer;

grant apply masking policy on account to role security_officer;

여기서:

  • schema_name

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

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

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

하이브리드 관리

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

use role accountadmin;
create role security_officer;
grant create masking policy on schema <db_name.schema_name> to role security_officer;

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

use role security_officer;
grant apply on masking policy ssn_mask to role human_resources;

여기서:

  • grant apply on masking policy policy_name to role role_name;

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

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

분산형 방식

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

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

use role accountadmin;
grant create masking policy on schema <db_name.schema_name> to role support;
grant create masking policy on schema <db_name.schema_name> to role finance;

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

use role support;
grant apply on masking policy ssn_mask to role human_resources;

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

use role finance;
grant apply on masking policy cash_flow_mask to role audit_internal;

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

마스팅 정책 DDL

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

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

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

작업

권한

마스킹 정책 생성

SCHEMA 권한에 대한 CREATE MASKING POLICY가 있는 역할.

마스킹 정책 변경

마스킹 정책 소유자(즉, 마스킹 정책에 대한 OWNERSHIP 권한이 있는 역할).

마스킹 정책 삭제

마스킹 정책 소유자(즉, 마스킹 정책에 대한 OWNERSHIP 권한이 있는 역할).

마스킹 정책 표시

다음 중 하나: . 전역 APPLY MASKING POLICY 권한이 있는 역할, 또는 . 마스킹 정책 소유자(즉, 마스킹 정책에 대한 OWNERSHIP 권한이 있는 역할), 또는 . 마스킹 정책에 대한 APPLY 권한이 있는 역할.

마스킹 정책 설명

다음 중 하나: . 전역 APPLY MASKING POLICY 권한이 있는 역할, 또는 . 마스킹 정책 소유자(즉, 마스킹 정책에 대한 OWNERSHIP 권한이 있는 역할), 또는 . 마스킹 정책에 대한 APPLY 권한이 있는 역할.

마스킹 정책이 있는 열의 목록

다음 중 1개: . APPLY MASKING POLICY 권한이 있는 역할 또는 . 지정된 마스킹 정책에서 MASKING POLICY 권한에 대한 APPLY가 있고 대상 오브젝트에 대한 OWNERSHIP이 있는 역할.

마스킹 정책에서 UDFs 사용하기

새로운 마스킹 정책을 생성하거나 기존 마스킹 정책을 변경하는 경우 정책 관리자 역할은 UDF를 사용할 수 있어야 하며, 정책 식의 모든 스칼라 UDFs는 데이터 타입이 동일하고 UDF가 있어야 합니다.

쿼리 런타임 시에 Snowflake는 UDF가 있는지 확인하며, 없는 경우 SQL 식이 확인되지 않고 쿼리가 실패합니다.

다음 항목:

맨 위로 이동