고급 Column-level Security 항목¶

CURRENT_ROLE 및 IS_ROLE_IN_SESSION 사용하기¶

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

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

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

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이 반환하는 실행 컨텍스트와 값을 요약하여 보여줍니다.

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

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)의 뷰 열에 적용되는 다음 마스킹 정책 본문을 생각해 보겠습니다.

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. 지정된 역할이 뷰 소유자 역할 계층 구조 내에 있는지 판단합니다.

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 작업에서 값이 사용될 수 있는 마스킹 정책에서는 해시, 암호화 또는 체크섬 함수를 절대로 사용하지 않는 것이 좋습니다.