고급 열 수준 보안 항목¶

CURRENT_ROLE 및 IS_ROLE_IN_SESSION 사용하기¶

CURRENT_ROLE을 사용하는 마스킹 정책 조건의 대상은 현재 세션이며 SQL 문의 실행 컨텍스트로부터 영향을 받지 않습니다.

정책 조건에서 역할 활성화 및 역할 계층 구조가 필요한 경우 IS_ROLE_IN_SESSION 을 사용합니다.

다음 마스킹 정책 본문을 고려하십시오.

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
  ELSE '********'
END;

Copy

지정된 사용자에게 이 마스킹 정책이 해당 열에 설정된 열의 데이터를 볼 수 있는 권한이 있는지 판단하려면 다음 단계를 완료하십시오.

1. 마스킹 정책 조건을 평가합니다.

2. 지정된 역할이 CURRENT_ROLE 계층 구조에 있는지 판단합니다.

3. 확인할 테스트 쿼리를 실행합니다.

USE ROLE analyst;

SELECT * FROM mydb.mysch.mytable;

INVOKER_ROLE 사용하기¶

INVOKER_ROLE을 사용하는 마스킹 정책 조건의 대상은 SQL 문의 실행 컨텍스트입니다.

다음 테이블은 마스킹 정책 조건에서 INVOKER_ROLE이 반환하는 실행 컨텍스트와 값을 요약하여 보여줍니다.

테이블의 단일 뷰에 적용되는 다음 마스킹 정책 본문을 생각해 보십시오.

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN INVOKER_ROLE() IN ('ANALYST') THEN val
  ELSE '********'
END;

Copy

열에 대해 쿼리를 실행하는 지정된 사용자에게 데이터를 볼 수 있는 권한이 있는지 판단하려면 다음 단계를 완료하십시오.

1. 마스킹 정책 조건을 평가합니다.

2. 지정된 역할이 뷰를 소유하는지 판단합니다.

3. 확인할 테스트 쿼리를 실행합니다.

SHOW GRANTS OF ROLE analyst;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

IS_GRANTED_TO_INVOKER_ROLE 사용하기¶

조건의 일부로 IS_GRANTED_TO_INVOKER_ROLE 함수를 마스킹 정책 본문에 전달할 수 있습니다. 함수의 결과가 TRUE이면 함수 인자의 역할이 INVOKER_ROLE 계층 구조에 있는 것입니다.

소셜 시큐리티 번호(SSNs)의 뷰 열에 적용되는 다음 마스킹 정책 본문을 생각해 보겠습니다.

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN IS_GRANTED_TO_INVOKER_ROLE('PAYROLL') THEN val
  WHEN IS_GRANTED_TO_INVOKER_ROLE('ANALYST') THEN REGEXP_REPLACE(val, '[0-9]', '*', 7)
  ELSE '*******'
END;

뷰 열에서 쿼리를 실행하는 지정된 사용자에게 데이터를 볼 수 있는 권한이 있는지 판단하려면 다음 단계를 완료합니다.

1. 마스킹 정책 조건을 평가합니다.

2. 지정된 역할이 호출자 역할 계층 구조 내에 있는지 판단합니다. 예를 들어 정책이 뷰에 설정된 경우 TRUE를 반환하려면 지정된 역할이 뷰 소유자 역할 계층에 있어야 합니다. 자세한 내용은 사용법 노트 를 참조하십시오.

3. 확인할 테스트 쿼리를 실행합니다.

USE ROLE payroll;

SELECT * FROM mydb.mysch.myview;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

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

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

마스킹 정책 에서 이러한 함수를 구현하기 전, 이러한 함수의 사용 사례에 JOIN 작업이 포함되는지 여부를 고려하는 것이 중요합니다. 특정 마스킹 정책 구현의 경우, 테이블 및 뷰가 포함되는 창의적인 JOIN 작업은 다음 제한 사항에 따라 마스킹된 값을 실제 값으로 리버스 엔지니어링하는 것이 가능합니다.

• 실제 값(즉, 입력)과 변환할 총 값 수(즉, 출력, 값 범위)를 기반으로 하는 해시, 암호화 또는 체크섬 값의 1:1 표현이 없기 때문에 충돌이 발생할 수 있습니다.

입력 값의 총 수가 변환할 출력 값의 제곱근에 도달할 때까지 1:1 표현이 발생할 가능성이 더 높습니다.

예를 들어, 해시에 대한 출력 값이 144이면 처음 12개 값(즉, 144^(1/2) – 144의 제곱근)이 고유하고 나머지 132개의 값에서 충돌이 발생할 수 있다고 예상하는 것은 합리적입니다. 이러한 제한 및 해당 결과가 가능하기 때문에, JOIN 작업에서 값이 사용될 수 있는 마스킹 정책에서는 해시, 암호화 또는 체크섬 함수를 절대로 사용하지 않는 것이 좋습니다.