데이터 웨어하우스 보안: 데이터 둔감화 기술에 대한 심층 분석

오픈소스 중국 커뮤니티 팀이 공유라는 이름으로 오픈소스 중국 커뮤니티의 뒷이야기를 전하는 첫 생방송을 진행했습니다."

이 기사는 VV Yixiao가 Huawei 클라우드 커뮤니티에서 공유한 " GaussDB(DWS) 보안 관리의 데이터 둔감화 원칙 및 사용 방법 소개 "입니다.

1. 소개

적용 가능한 버전: 8.2.0 이상

GaussDB(DWS) 제품 데이터 둔감화 기능은 데이터베이스 제품이 데이터 보안 기능을 내재화하고 통합하는 중요한 기술 혁신입니다. 지정된 사용자 범위 내에서 열 수준의 민감한 데이터에 대한 민감도 감소 기능을 제공합니다. 유연성, 효율성, 투명성, 친숙성 등의 장점이 있습니다. 제품의 데이터 보안 기능을 크게 향상시키고 민감한 데이터를 안정적으로 보호합니다. .

빅데이터 시대의 도래는 전통적인 비즈니스의 운영 모델을 전복시키고 새로운 생산 잠재력을 자극했습니다. 데이터는 생산의 중요한 요소이자 정보 전달자가 되었으며, 데이터의 흐름은 고차원적인 가치 정보를 숨기기도 합니다. 데이터 컨트롤러와 데이터 처리자에게 데이터 흐름의 가치를 극대화하는 방법은 데이터 마이닝의 원래 의도이자 의미입니다. 그러나 일련의 정보 유출 사건이 노출되면서 데이터 보안에 대한 관심이 더욱 광범위해졌습니다. 국가와 지역에서는 사용자 개인정보 보호에 대한 법적 보호를 제공하기 위해 데이터 보안 및 개인정보 보호와 관련된 법률 및 규정을 점차적으로 제정 및 개선하고 있습니다. 기술 수준에서 데이터 보안 및 개인 정보 보호를 강화하고 데이터 웨어하우스 제품 자체에 대해 더 많은 기능적 요구 사항을 제시하는 것도 데이터 보안을 구축하는 가장 효과적인 방법입니다.

GaussDB(DWS) 제품 버전 8.1.1에서는 지정된 사용자 범위 내에서 열 수준의 민감한 데이터에 대한 민감도 감소 기능을 제공하는 데이터 민감도 감소 기능을 출시합니다. 유연성, 효율성, 투명성, 친숙성이라는 장점이 있으며, 제품의 데이터 보안 기능.

2. 데이터 둔감화의 개념

데이터 마스킹은 이름에서 알 수 있듯이 민감한 데이터를 보호하는 것입니다. 유출될 경우 사회나 개인에게 심각한 해를 끼칠 수 있는 데이터는 모두 민감한 데이터입니다. 이름, 주민등록번호, 주소, 휴대전화번호, 이메일 주소 등 개인 식별 정보는 기업이 사업자등록번호, 과세등록증, 직원 급여, IP 주소, MAC 등 기기 정보 등의 정보를 공개하는 데 적합하지 않습니다. 주소, 은행 카드 번호, 보호되는 건강 정보, 지적 재산권 등은 모두 민감한 정보입니다. 이 민감한 정보는 민감도 줄이기 규칙을 통해 변형되어 개인 데이터를 안정적으로 보호합니다. 업계의 일반적인 감도 줄이기 규칙에는 대체, 재배열, 암호화, 자르기 및 마스킹이 포함됩니다. 사용자는 원하는 감도 줄이기 알고리즘을 기반으로 감도 줄이기 규칙을 사용자 정의할 수도 있습니다.

일반적으로 데이터 민감도 감소를 제대로 구현하려면 다음 두 가지 원칙을 따라야 합니다. 첫째, 민감도 감소 이후 애플리케이션에 대한 민감도 감소 이전에 의미 있는 정보를 유지해야 합니다. 둘째, 해커의 크래킹을 최대한 방지해야 합니다.

데이터 둔감화는 정적 데이터 둔감화와 동적 데이터 둔감화로 구분됩니다. 정적 데이터 둔감화는 데이터의 "이동 및 시뮬레이션 대체"입니다. 데이터가 추출되고 둔감화된 후 무료 액세스, 읽기 및 쓰기를 위해 다운스트림 링크로 전송됩니다. 둔감화 후 데이터는 생산 환경에서 격리됩니다. 프로덕션 데이터베이스의 보안을 보장하면서 비즈니스 요구 사항을 충족합니다. 동적 데이터 감도 줄이기는 민감한 데이터에 액세스하는 동안 실시간으로 감도 줄이기 처리를 수행하여 다양한 역할, 다양한 권한 및 다양한 데이터 유형에 대해 다양한 감도 줄이기 체계를 구현하여 반환된 데이터의 가용성과 안전성을 보장합니다.

2.1 DWS 동적 데이터 둔감화

GaussDB(DWS)의 데이터 둔감화 기능은 비즈니스 애플리케이션 계층에서 높은 의존도와 높은 둔감화 비용이라는 문제점을 버리고, 데이터 둔감화를 데이터베이스 제품 자체의 보안 기능에 내재화하여 완전하고 안전하며 유연하고 투명한 데이터 보안을 제공합니다. 동적 데이터 둔감화에 속하는 친숙한 데이터 둔감화 솔루션 세트입니다. 사용자는 민감한 필드를 식별한 후 대상 필드를 기반으로 내장된 마스킹 기능을 바인딩하여 마스킹 정책을 생성할 수 있습니다. 수정 정책은 테이블 개체와 다대일 관계를 갖습니다. 마스킹 전략에는 테이블 객체, 유효 조건, 마스킹된 열-마스크된 함수 쌍의 세 가지 핵심 요소가 포함됩니다. 이는 테이블 객체의 모든 마스킹된 열의 모음입니다. 서로 다른 필드는 데이터 특성에 따라 서로 다른 마스킹 기능을 사용할 수 있습니다. 유효 조건과 둔감화 열-민감화 함수 쌍에 따라 동일한 테이블에 전략을 설정할 수도 있습니다. 유효 조건이 true인 경우에만 쿼리 문은 민감한 데이터의 감도 저하를 트리거합니다. 감도 저하 프로세스는 SQL 엔진에 내장되어 있으며 프로덕션 환경 사용자에게 투명하고 보이지 않습니다.

타사 에이전트 감도 줄이기 도구와 데이터 웨어하우스 DWS 감도 줄이기 엔진

타사 프록시 도구는 사용자와 데이터 웨어하우스 클러스터 간의 전송 스테이션입니다. 이는 기반 외부의 플러그인 민감도 감소 도구로, 생성 환경에 직접 참여할 수 없으며 복잡한 시나리오를 처리하기 어렵습니다.

DWS는 데이터 웨어하우스 기반과 스토리지 엔진, SQL 엔진 간의 직접적인 상호 작용을 기반으로 하는 Desensitization 엔진으로, 쿼리 실행 과정에서 실시간 Desensitization을 수행하고, Desensitization 결과를 사용자에게 직접 반환합니다.

에이전트 둔감화 도구는 정적 둔감화이고, DWS 둔감화 엔진은 동적 둔감화입니다.

DWS 동적 둔감화 엔진의 장점

베이스 시너지가 좋습니다. 감도 줄이기 엔진은 데이터 웨어하우스 기반의 여러 측면을 통해 실행되며 사전 설정된 감도 줄이기 전략을 기반으로 SQL 엔진의 구문 분석, 재작성, 최적화 및 실행에 참여합니다. 둔감화 과정은 사용자에게 보이지 않습니다.

정책은 구성 가능합니다. 고객은 자신의 비즈니스 시나리오와 비즈니스 테이블의 지정된 열에 대해 유연하게 미리 설정된 감도 줄이기 전략을 기반으로 중요한 데이터를 식별할 수 있습니다.

전략은 확장 가능합니다. 이 제품에는 가장 일반적인 둔감화 효과를 처리할 수 있는 둔감화 기능이 내장되어 있으며 사용자 정의 둔감화 기능을 지원합니다.

데이터 가용성. 데이터베이스의 원래 민감한 데이터는 작업에 참여하며 데이터베이스를 떠날 때(결과가 반환될 때)에만 민감도가 낮아집니다.

데이터 액세스가 제어됩니다. 민감도 줄이기 정책이 적용되는 조건에서는 원래의 민감한 데이터가 사용자에게 표시되지 않습니다.
모든 장면 데이터는 유출되지 않습니다. 기본 상호 작용은 민감한 데이터 전송 링크의 유출 위험을 줄일 수 있습니다.

더욱 안전하고 안정적이며 다양한 잠재적인 악성 피싱 시나리오를 완벽하게 식별하고 효과적인 보호를 제공합니다.

3. 데이터 둔감화 사용 방법

동적 데이터 감도 줄이기는 쿼리 문 실행 중에 유효 조건이 충족되는지 여부를 기반으로 하는 실시간 감도 줄이기 프로세스입니다. 유효성 검사 조건은 일반적으로 현재 사용자 역할의 판단을 기반으로 합니다. 민감한 데이터의 가시 범위는 다양한 사용자에 대해 미리 설정되어 있습니다. 시스템 관리자는 가장 높은 권한을 가지며 언제든지 모든 테이블의 모든 필드를 볼 수 있습니다. 제한된 사용자 역할을 식별하는 것은 둔감화 전략을 수립하는 첫 번째 단계입니다.

민감한 정보는 실제 비즈니스 시나리오 및 보안 차원에 따라 다릅니다. 자연인을 예로 들면, 개인 사용자의 민감한 필드에는 고객으로서 이름, ID 번호, 휴대폰 번호, 이메일 주소 등이 포함됩니다. , 회사 시스템에서는 은행 카드 번호, 만료 시간, 결제 비밀번호 등이 포함될 수도 있고, 환자로서 의료 시스템에서도 급여, 학력 등이 포함될 수 있습니다. 진료정보 등도 포함됩니다. 따라서 특정 비즈니스 시나리오에서 민감한 필드를 식별하고 분류하는 것은 둔감화 전략 수립의 두 번째 단계입니다.

이 제품에는 일련의 공통 둔감화 기능 인터페이스가 내장되어 있어 다양한 데이터 유형 및 데이터 특성에 대한 매개변수를 지정하여 다양한 둔감화 효과를 얻을 수 있습니다. 감도 줄이기 기능은 다음 세 가지 내장 인터페이스를 사용할 수 있으며 사용자 정의 감도 줄이기 기능도 지원합니다. 세 가지 기본 제공 감도 저하 기능은 대부분의 시나리오에서 감도 저하 효과를 처리할 수 있습니다. 사용자 정의 감도 저하 기능을 사용하는 것은 권장되지 않습니다.

MASK_NONE: 둔감화 없음, 내부 테스트용으로만 사용됩니다.
MASK_FULL: 고정된 값으로 완전히 둔감화됩니다.
MASK_PARTIAL: 지정된 마스킹 문자를 사용하여 마스킹 범위 내의 콘텐츠를 부분적으로 마스킹합니다.

다양한 둔감화 열은 다양한 둔감화 기능을 사용할 수 있습니다. 예를 들어 휴대폰 번호는 일반적으로 마지막 4자리를 표시하고 앞의 숫자를 "*"로 대체하여 금액을 0 등의 고정값으로 일률적으로 표시합니다. 둔감화 열에 바인딩되어야 하는 둔감화 함수를 결정하는 것은 둔감화 전략을 만드는 세 번째 단계입니다.

회사의 직원 테이블 emp, 테이블 소유자 사용자 alice, 사용자 matu 및 july를 예로 들어 데이터 둔감화의 사용 프로세스를 간략하게 소개합니다. 그 중 emp 테이블에는 직원의 이름, 휴대폰 번호, 이메일, 카드 번호, 급여 및 기타 개인 데이터가 포함되어 있습니다. 사용자 Alice는 인사 관리자이고 사용자 Matu와 July는 일반 직원입니다.

emp 테이블에 대한 테이블, 사용자 및 사용자의 보기 권한이 모두 있다고 가정합니다.

1. Alice가 모든 직원 정보만 볼 수 있도록 허용하는 둔감화 정책 마스크_emp를 만듭니다. Matu와 July는 급여 카드 번호와 급여에 표시되지 않습니다. 카드 번호 필드는 숫자 유형이고 MASK_FULL은 고정 값 0으로 완전히 둔감화하는 데 사용됩니다. 카드 문자열 필드는 문자 유형이고 MASK_PARTIAL은 지정된 입력 및 출력 형식에 따라 원본 데이터를 부분적으로 둔감하게 하는 데 사용됩니다. 필드 급여는 숫자 유형이며 숫자 9는 끝에서 두 번째 숫자 앞의 모든 숫자 값을 부분적으로 둔감하게 하는 데 사용됩니다.

postgres=# 편집 정책 생성 마스크_emp ON emp WHEN (current_user != 'alice')

마스크_가득함(card_no)을 사용하여 COLUMN 카드_번호를 추가합니다.

마스크_부분(카드 문자열, 'VVVVFVVVVFVVVVFVVVV','VVVV-VVVV-VVVV-VVVV','#',1,12),

ADD COLUMN 급여 WITH Mask_partial(salary, '9', 1, length(salary) - 2);

matu 및 july로 전환하고 직원 테이블 emp를 확인합니다.

postgres=> 역할 설정 matu 비밀번호 'Gauss@123';

postgres=> SELECT * FROM emp;

 아이디 | 이름 | 전화번호 | 카드번호 | 카드 문자열 | 이메일 | 급여 | 생일       

----+------+------------+---------+-------------- -------+---------+------------+------ ---------------

  1 | 애니 | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00

  2 | 밥 | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00

  3 | 시시 | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00

(3열)

postgres=> 역할 설정 7월 비밀번호 'Gauss@123';

postgres=> SELECT * FROM emp;

 아이디 | 이름 | 전화번호 | 카드번호 | 카드 문자열 | 이메일 | 급여 | 생일       

----+------+------------+---------+-------------- -------+---------+------------+------ ---------------

  1 | 애니 | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00

  2 | 밥 | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00

  3 | 시시 | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00

(3열)

2. 업무 조정으로 인해 matu는 인사부에 들어가 회사의 채용 문제에 참여했으며 모든 직원 정보도 공개되어 정책의 유효 조건이 수정되었습니다.

postgres=> 편집 정책 변경 Mask_emp ON emp WHEN(current_user NOT IN ('alice', 'matu'));

matu 및 july 사용자로 전환하고 직원 테이블 emp를 다시 봅니다.

postgres=> 역할 설정 matu 비밀번호 'Gauss@123';

postgres=> SELECT * FROM emp;

 아이디 | 이름 | 전화번호 | 카드번호 | 카드 문자열 | 이메일 | 급여 | 생일       

---+------+-------------+------+----- -+---------+---------- ---+---------

  1 | 애니 | 13420002340 | 1234123412341234 | 1234-1234-1234-1234 | [email protected] | 10000.0000 | 1999-10-02 00:00:00

  2 | 밥 | 18299023211 | 3456345634563456 | 3456-3456-3456-3456 | [email protected] | 9999.9900 | 1989-12-12 00:00:00

  3 | 시시 | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00

(3열)

postgres=> 역할 설정 7월 비밀번호 'Gauss@123';

postgres=> SELECT * FROM emp;

 아이디 | 이름 | 전화번호 | 카드번호 | 카드 문자열 | 이메일 | 급여 | 생일       

----+------+------------+---------+-------------- -------+---------+------------+------ ---------------

  1 | 애니 | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00

  2 | 밥 | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00

  3 | 시시 | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00

(3열)

3. 직원 정보(phone_no, email, birthday)도 비공개 데이터입니다. Mask_emp 마스킹 정책을 업데이트하고 마스킹 열 3개를 추가합니다.

postgres=> 편집 정책 변경 Mask_emp ON emp ADD COLUMN Phone_no WITH Mask_partial(phone_no, '*', 4);

postgres=> ALTER REDACTION POLICY Mask_emp ON emp ADD COLUMN email WITH Mask_partial(email, '*', 1, position('@' in email));

postgres=> ALTER REDACTION POLICY 마스크_emp ON emp ADD COLUMN 생일 WITH Mask_full(생일);

사용자 july로 전환하고 직원 테이블 emp를 확인합니다.

postgres=> 역할 설정 7월 비밀번호 'Gauss@123';

postgres=> SELECT * FROM emp;

 아이디 | 이름 | 전화번호 | 카드번호 | 카드 문자열 | 이메일 | 급여 | 생일       

----+------+------------+---------+-------------- -------+---------+------------+------ ---------------

  1 | 애니 | 134********* | 0 | ####-####-####-1234 | ********163.com | 99999.9990 | 1970-01-01 00:00:00

  2 | 밥 | 182********* | 0 | ####-####-####-3456 | ***********qq.com | 9999.9990 | 1970-01-01 00:00:00

  3| 시시 | 155******** | | | **************sina.com | | 1970-01-01 00:00:00

(3열)

4. GaussDB(DWS)는 사용자 상호 작용의 편의성을 고려하여 사용자가 더 많은 둔감화 정보를 직접 볼 수 있도록 시스템 뷰 redaction_policies 및 redaction_columns를 제공합니다.

postgres=> SELECT * FROM redaction_policies;

 객체_스키마 | 객체_소유자 | 객체_이름 | 정책_이름 | 표현 | 활성화 | 정책_설명

---------------+---------------+-------------+---- ------+---------+----- ---+---------

 공개 | 앨리스 | 엠프 | 마스크_emp | ("current_user"() = '7월'::이름) | 티 |

(1줄)

postgres=> redaction_columns에서 object_name, column_name, function_info를 선택합니다.

 객체_이름 | 컬럼_이름 | function_info                                             

-----------+-------------+--------- ------------------------------------- ------------------

 엠프 | 카드번호 | 마스크_가득(card_no)

 엠프 | 카드 문자열 | Mask_partial(카드_문자열, 'VVVVFVVVVFVVVVFVVVV'::text, 'VVVV-VVVV-VVVV-VVVV'::text, '#'::text, 1, 12)

 엠프 | 이메일 | Mask_partial(이메일, '*'::text, 1, "position"(이메일, '@'::text))

 엠프 | 급여 | Mask_partial(급여, '9'::text, 1, (length((급여)::text) - 2))

 엠프 | 생일 | 마스크_가득(생일)

 엠프 | 전화 번호 | Mask_partial(phone_no, '*'::텍스트, 4)

(6열)

5. 어느 날 갑자기 회사 내에서 직원 정보를 공유할 수 있게 되면 emp 테이블의 마스킹 정책인 Mask_emp를 삭제하면 됩니다.

postgres=> 삭제 정책 삭제 Mask_emp ON emp;

자세한 사용법은 GaussDB(DWS) 제품 문서를 참고하세요.

4. 보이지 않는 데이터 둔감화

데이터 둔감화 기능을 사용하는 경우 민감한 데이터를 처리하여 출력하기 전에 계산하는 경우가 있을 수 있습니다. 이 경우 둔감화된 데이터를 데이터베이스 내 계산에 사용하면 둔감화된 데이터 자체가 집계 함수 및 필터 조건과 같은 조건에서 쿼리 결과에 영향을 미치므로 이 현상을 해결하기 위해 둔감화된 데이터가 사용됩니다. .민은 보이지 않는 것으로 간주하는 기능을 도입합니다. 소위 보이지 않는다는 것은 원래의 민감한 데이터가 데이터베이스에서 처리 계산에 참여하는 데 사용되며, 민감한 데이터가 데이터베이스 밖으로 나올 때만 민감도가 낮아지는 것을 의미합니다. 계산 가능한 보이지 않음 기능을 사용하려면 스위치를 활성화_redactcol_computable=on으로 설정해야 합니다.

현재 계산 처리에 민감한 데이터의 직접적인 참여를 지원하는 시나리오는 다음과 같습니다.

SELECT nullif(salary, 1) FROM emp;
SELECT 이메일 LIKE '%.com' FROM emp;
SELECT to_days(birth) FROM david.emp 투영 열 함수 to_days;
SELECT count(*) FROM emp;
SELECT * FROM emp WHERE 카드ID는 NULL이 아닙니다.
SELECT name, avg(salary) * 12 FROM emp GROUP BY name; 그룹화 조건(name은 민감하지 않은 필드)
SELECT (SELECT 급여+10 FROM emp ORDER BY id LIMIT 1);
두 테이블은 중요한 필드를 연결 조건으로 사용합니다.
CTE 표현식 예상 열

배송 시 데이터 둔감화를 트리거하는 시나리오는 다음과 같습니다.

테이블 쿼리
쿼리 보기
DML RETURNING 절
COPY내보내기
GDS 테이블 내보내기
커서… 가져오기
저장 프로시저 정의는 마스크된 테이블을 사용하여 저장 프로시저를 쿼리합니다.

4.1 둔감화 전략의 계승

INSERT/UPDATE/MERGE INTO/CREATE TABLE AS 문의 경우 하위 쿼리가 중요한 필드에 대한 프로젝션 작업인 경우 민감한 정보가 포함된 새 테이블에 원본 테이블과 동일한 정보가 포함되도록 민감도가 낮아지는 상속이 트리거됩니다. 전략은 원본 테이블의 민감한 데이터를 새 테이블에 삽입한 다음 새 테이블을 쿼리하여 민감한 데이터가 유출되는 문제를 방지합니다. 또한, 마스킹 정책의 상속은 테이블 차원 활동에 속하며, 상속 활동은 하위 쿼리 부분의 현재 세션이나 역할 조건에서 마스킹 정책이 적용되는지 여부에 주의를 기울이지 않습니다.

감도 줄이기 전략을 상속하는 첫 번째 단계는 민감한 계보 분석을 수행하는 것입니다. 모든 사용자가 DML 문을 실행하려면 원본 테이블과 해당 대상 프로젝션 열의 하위 쿼리 부분이 순회됩니다. 대상 프로젝션 컬럼은 둔감화 필드이므로, 소스 테이블을 사용하여 대상 테이블 데이터를 삽입/업데이트할 때 소스 테이블의 민감한 데이터가 노출될 위험이 있다고 간주됩니다.

마스킹 전략을 상속할 때 먼저 순회에 표시된 소스 테이블의 민감한 정보에서 대상 테이블에 적용되는 마스킹 전략 정보와 마스킹 필드 정보를 생성합니다. 그런 다음 시스템 내장은 정책 생성 문을 생성하고 이를 시스템 테이블 pg_redaction_policy/pg_redaction_column에 기록합니다. 내장 둔감화 정책의 이름은 "inherited_rp"입니다. 마지막으로 시스템 테이블 메타데이터 상속 표시 필드를 true로 설정합니다.

INSERT 실행 세션/사용자가 트리거 조건을 충족하는 경우 삽입 결과가 RETURNING 절과 함께 인쇄되면 반환된 결과는 둔감화되고 로그 정보 "상위 수정 정책/열"에는 정책 상속의 소스가 기록됩니다. .

둔감화 정책 상속 동작이 도입되면서 일부 둔감화 정책 충돌 시나리오가 발생했습니다. 예를 들어 SELECT 문 쿼리의 대상 열은 원래 민감한 필드가 아니라 민감한 필드의 복잡한 표현식입니다. 이 경우 감도 저하 동작을 어떻게 정의합니까? SETOP 집합 연산의 두 하위 분기는 동일한 대상 열에 대해 서로 다른 감도 저하 효과를 사용합니다. 이때 외부 문의 대상 열에 대한 감도 저하 결과를 어떻게 정의합니까? 여러 INSERT/UPDATE 작업에 대한 민감한 계보 분석에서 동일한 대상 열의 소스 테이블 프로젝션 열은 서로 다른 감도 줄이기 효과를 채택하며 소스 테이블 정책의 유효 조건도 이 경우 감도 줄이기 정책을 어떻게 상속해야 합니까? ?

이러한 충돌 시나리오의 경우, 사용자의 민감한 데이터가 유출되지 않도록 보호하는 것이 원래의 특성을 갖지 않는 민감한 데이터의 둔감화 효과보다 우선한다는 원칙에 따라 둔감화 효과 충돌이 발생하면 일반으로 업그레이드됩니다. 둔감화 효과mask_full. Mask_full은 모든 데이터 유형을 포괄할 수 있는 전체 마스킹 함수입니다. 표현식 반환 값 유형에만 중점을 두어 마스킹된 데이터가 유출되지 않도록 보장할 수 있습니다. 그러나 마스킹된 결과는 데이터 유형의 특성을 나타낼 수 없습니다. 원본 데이터로 인해 마스크된 결과를 읽기가 어렵습니다. 또한 길이, 개수 등의 함수 표현식의 경우 계산 결과는 원본 데이터 특성 및 정보를 노출하지 않으므로 사용자가 민감도를 낮추지 않는 함수를 수동으로 구성할 수 있도록 ALTER FUNCTION ... [NOT] MASKED 구문이 제공됩니다. 화이트리스트.

4.2 악성 피싱으로부터 보호

특정 민감한 정보가 알려져 있으며, 여러 번의 경험적 일치를 통해 눈에 보이는 사용자 정보를 역으로 확증하여 사용자의 개인 데이터를 훔칩니다. 동등성 판단의 형태로 표현을 지원하는 필터 조건 또는 프로젝션 작업을 사용하여 민감한 정보를 경험적으로 일치시킵니다. 알려진 상수 값과 동등/유사 동등 판단 표현을 통해 사용자 개인정보를 추출하는 이러한 행위는 악의적인 시도입니다.

postgres=> SELECT name FROM emp WHERE name in('张三');

INFO: 대상 열 {"name"}의 결과가 마스킹되었습니다.

 이름

------

  열려 있는*

 (1줄)

위의 예에서 볼 수 있듯이, 사용자의 이름 정보가 'Zhang San'에 대한 쿼리 조건이므로 'Zhang*'으로 둔감화되더라도 여기서는 여전히 쉽게 둔감화를 확인할 수 있습니다. 민감한 정보는 '장산(Zhang San)'으로, 이로 인해 장산(Zhang San)의 사용자 정보가 유출될 위험이 있습니다.

이 문제에 대응하여 우리는 "비관적" 모델을 채택했습니다. 지속적인 동등성 판단은 악의적인 차익거래의 위험이 있으므로 금지되어야 합니다. 예는 다음과 같습니다.

postgres=> SELECT name FROM emp WHERE name in('张三');

오류: 수정 열 "name"은 const 값이 있는 동등 조건에서 참조될 수 없습니다.

힌트: 자세한 내용을 보려면 EXPLAIN 명령을 사용하세요.

상수를 사용한 악의적인 차익 거래가 금지되는 시나리오는 다음과 같이 요약됩니다.

1. 둔감화된 필드에 대한 상수 동등성 판단 표현식, 복합 표현식 및 등가 표현식

2. 이름 필드가 민감하지 않은 필드이고 현재 세션이 정책 트리거 조건을 충족한다고 가정하면 명령문은 다음과 같은 특성을 가지며 악의적인 차익 거래의 위험이 있으며 실행이 금지됩니다.

• 이름 = '장산'

• 이름 = '장산' OR 이름 = '이思'

• 이름('장산', '이思')

• CASE 이름 WHEN '张三' THEN 참…

• 이름이 ('张三', 'lee思')인 경우 THEN …

• 고급 패키지 dbms_output.put_line

3. 명령문이 실행되면 오류가 보고됩니다. 오류: 편집 열 "name"은 const 값이 있는 동등 조건에서 참조될 수 없습니다.

5. 데이터 둔감화의 구현 원리

GaussDB(DWS) 데이터 둔감화 기능은 기존 SQL 엔진 구현 프레임워크를 기반으로 제한된 사용자가 쿼리문을 실행하는 동안 외부 세계에서 감지할 수 없는 실시간 둔감화 처리를 가능하게 합니다. 내부 구현에 대해서는 위 그림에 나와 있습니다. 우리는 수정 정책을 테이블 개체에 바인딩된 규칙으로 간주합니다. 최적화 프로그램의 쿼리 재작성 단계에서는 기본 테이블의 수정 열이 포함된 경우 쿼리 트리에 있는 TargetList의 각 TargetEntry가 순회됩니다. 둔감화 규칙이 적용되면(즉, 둔감화 정책의 유효 조건이 충족되고 활성화됨), 둔감화할 Var 객체가 이 TargetEntry에 포함된다는 결론이 나옵니다. 이때 둔감화 열 시스템 테이블은 다음과 같습니다. pg_redaction_column을 탐색하여 해당 둔감화 열 바인딩을 찾습니다. 특정 둔감화 함수는 해당 FuncExpr로 대체될 수 있습니다. 위에서 쿼리 트리를 다시 작성한 후 최적화 프로그램은 자동으로 새 실행 계획을 생성하고 실행 프로그램은 새 계획에 따라 실행되며 쿼리 결과는 민감한 데이터에 민감하지 않게 됩니다.

원래 문과 비교하여 데이터 감도 줄이기를 사용한 문 실행은 데이터 감도 줄이기의 논리적 처리를 추가하므로 필연적으로 쿼리에 추가 오버헤드가 발생합니다. 이 비용은 주로 테이블의 데이터 크기, 대상 열 쿼리에 포함된 마스킹된 열 수, 마스킹된 열에 사용된 마스킹 기능의 세 가지 요소에 의해 영향을 받습니다.

간단한 쿼리문의 경우 다음 그림과 같이 tpch 테이블 customer를 예로 들어 위의 요소를 테스트합니다.

그림 (a)와 (b)에서 기본 테이블 고객은 필드 유형 및 특성에 따라 MASK_FULL 둔감화 함수 또는 MASK_PARTIAL 둔감화 함수를 사용합니다. MASK_FULL은 모든 길이와 유형의 원본 데이터만 고정된 값으로 둔감하게 하므로 출력 결과는 원본 데이터와 매우 다릅니다. 그림 (a)는 다양한 데이터 규모에서 둔감화된 시나리오와 둔감하지 않은 시나리오에서 단순 쿼리 문의 실행 시간을 보여줍니다. 단색 아이콘은 비민감화 시나리오를 나타내고, 속이 빈 아이콘은 제한된 사용자, 즉 둔감화 시나리오를 나타냅니다. 데이터 크기가 클수록 둔감화를 적용한 쿼리 시간과 원래 명령문 간의 차이가 더 커짐을 알 수 있습니다. 그림 (b)는 쿼리에 포함된 다양한 수의 마스킹된 열이 10x 데이터 규모에서 문 실행 성능에 미치는 영향을 보여줍니다. 마스킹된 컬럼이 1개 포함된 경우 마스킹된 쿼리는 원래 문보다 속도가 느려집니다. 이 컬럼은 MASK_PARTIAL 부분 마스킹 함수를 사용하므로 쿼리 결과는 결과의 형식만 변경되고 결과 내용의 길이도 변경됩니다. 이는 "민감화를 사용한 명령문 실행에 상응하는 성능 저하가 발생한다"는 이론적 추측과 일치합니다. 쿼리에 포함된 마스킹된 열의 수가 증가함에 따라 민감도가 낮아진 시나리오가 실제로 원래 문보다 빠르게 실행되는 이상한 현상을 발견했습니다. 다중 열 시나리오에서 마스킹된 열과 관련된 마스킹 함수를 추가로 추적한 결과, 출력 결과 집합이 원본 데이터에 비해 많은 시간을 절약하여 다중 열을 만드는 것은 바로 MASK_FULL 마스킹 함수를 사용하는 마스킹된 열 때문이라는 것을 발견했습니다. - 열 쿼리가 더 효율적입니다. 데이터 마스킹을 사용한 간단한 쿼리는 실제로 훨씬 빠릅니다.

위의 추측을 뒷받침하기 위해 마스킹 기능을 조정했습니다. 마스킹된 모든 열은 MASK_PARTIAL을 사용하여 원본 데이터를 부분적으로 마스킹하여 마스킹 결과에서 원본 데이터의 외부 가독성을 유지할 수 있습니다. 따라서 그림 ©에서 볼 수 있듯이 마스킹된 열이 모두 부분 마스킹 함수와 연결되어 있는 경우 데이터 마스킹이 적용된 문은 원래 문보다 약 10% 정도 성능 저하가 발생합니다. 이론적으로 이러한 성능 저하는 허용 가능한 범위 내에 있습니다. 위 테스트는 간단한 쿼리 문에만 적용됩니다. 문이 집계 함수나 복잡한 식 연산을 포함할 만큼 복잡할 경우 이러한 성능 저하가 더욱 명백해질 수 있습니다.

6. 요약

GaussDB(DWS) 제품 데이터 둔감화 기능은 데이터베이스 제품이 데이터 보안 기능을 내재화하고 통합하는 중요한 기술 혁신입니다. 주로 다음 세 가지 측면을 다룹니다.

데이터 둔감화 전략을 위한 간단하고 사용하기 쉬운 구문 세트입니다.

일반적인 개인 데이터 둔감화 효과를 다루는 일련의 유연하게 구성된 내장 둔감화 기능입니다.

완벽하고 편리한 둔감화 전략 적용 솔루션을 통해 실행 중 원래 문장의 실시간, 투명하고 효율적인 둔감화가 가능합니다.

전체적으로 이 데이터 감도 줄이기 기능은 고객 비즈니스 시나리오의 데이터 감도 줄이기 요구 사항을 완벽하게 충족하고, 일반적인 개인 데이터의 감도 줄이기 효과를 지원하며, 민감한 데이터를 안정적으로 보호할 수 있습니다.

[따뜻한 알림] 이용 중 궁금한 점이 있으시면 언제든지 편하게 소통하고 피드백을 주세요.

화웨이 클라우드의 신기술에 대해 빨리 알아보고 팔로우하려면 클릭하세요~