데이터 마스킹 소개

BigQuery는 열 수준에서 데이터 마스킹을 지원합니다. 데이터 마스킹을 사용하여 사용자 그룹의 열 데이터를 선택적으로 가릴 수 있지만 열 액세스를 계속 허용할 수 있습니다. 데이터 마스킹 기능은 열 수준 액세스 제어를 기반으로 빌드되므로 계속하기 전에 해당 기능을 숙지해야 합니다.

데이터 마스킹을 열 수준 액세스 제어와 함께 사용하면 여러 사용자 그룹의 요구사항에 따라 전체 액세스 권한에서 액세스 권한 없음까지 열 데이터에 대한 액세스 범위를 구성할 수 있습니다. 예를 들어 세금 ID 데이터의 경우 회계 그룹에 전체 액세스 권한을 부여하고, 분석가 그룹에 마스크 액세스 권한을 부여하고, 영업 그룹에는 액세스 권한을 부여하지 않을 수 있습니다.

이점

데이터 마스킹은 다음과 같은 이점을 제공합니다.

데이터 공유 프로세스가 간소화됩니다. 민감한 열을 마스킹하여 테이블을 더 큰 그룹과 공유할 수 있습니다.
열 수준 액세스 제어와 달리 사용자가 액세스할 수 없는 열을 제외하여 기존 쿼리를 수정할 필요가 없습니다. 데이터 마스킹을 구성하면 기존 쿼리가 자동으로 사용자에게 부여된 역할에 따라 열 데이터를 마스킹합니다.
데이터 액세스 정책을 대규모로 적용할 수 있습니다. 데이터 정책을 작성하여 정책 태그와 연결하고 정책 태그를 원하는 수의 열에 적용할 수 있습니다.
속성 기반 액세스 제어를 사용 설정합니다. 열에 연결된 정책 태그는 데이터 정책과 해당 정책 태그와 연결된 주 구성원에 의해 결정되는 컨텍스트 데이터 액세스를 제공합니다.

데이터 마스킹 워크플로

그림 1은 데이터 마스킹을 구성하는 워크플로를 보여줍니다.

데이터 마스킹을 사용 설정하려면 분류를 만들고 분류에서 정책 태그에 데이터 정책을 만든 다음 정책 태그를 테이블 열과 연결해야 합니다. 그림 1. 데이터 마스킹 구성요소

다음 단계에 따라 데이터 마스킹을 구성합니다.

분류 및 하나 이상의 정책 태그를 설정합니다.
정책 태그에 대한 데이터 정책을 구성합니다. 데이터 정책은 데이터 마스킹 규칙과 사용자 또는 그룹을 나타내는 하나 이상의 주 구성원을 정책 태그에 매핑합니다.

Google Cloud 콘솔을 사용하여 데이터 정책을 만드는 경우 데이터 마스킹 규칙을 만들고 한 번에 주 구성원을 지정합니다. BigQuery Data Policy API를 사용하여 데이터 정책을 만드는 경우 한 단계에서 데이터 정책 및 데이터 마스킹 규칙을 만들고 두 번째 단계에서 데이터 정책의 주 구성원을 지정합니다.
BigQuery 테이블의 열에 정책 태그를 할당하여 데이터 정책을 적용합니다.
마스킹된 데이터에 액세스해야 하는 사용자를 BigQuery 마스킹된 리더 역할에 할당합니다. 데이터 정책 수준에서 BigQuery 마스킹된 리더 역할을 할당하는 것이 좋습니다. 프로젝트 수준 이상에서 역할을 할당하면 사용자에게 프로젝트의 모든 데이터 정책에 대한 권한이 부여되어 과도한 권한으로 인한 문제가 발생할 수 있습니다.

데이터 정책과 연결된 정책 태그를 열 수준 액세스 제어에도 사용할 수 있습니다. 이 경우 정책 태그는 Data Catalog 세분화된 권한의 리더 역할이 부여된 하나 이상의 주 구성원과도 연결됩니다. 이렇게 하면 이러한 주 구성원이 마스킹 해제된 원래 열 데이터에 액세스할 수 있습니다.

그림 2는 열 수준 액세스 제어 및 데이터 마스킹이 함께 작동하는 방식을 보여줍니다.

정책 태그는 데이터 정책과 연결되어 데이터 마스킹을 구성한 후 테이블 열과 연결되어 마스킹을 사용 설정합니다. 그림 2. 데이터 마스킹 구성요소

역할 상호작용에 대한 자세한 내용은 마스킹된 리더 및 세분화된 권한의 리더 역할 상호작용 방법을 참조하세요. 정책 태그 상속에 대한 자세한 내용은 역할 및 정책 태그 계층 구조를 참조하세요.

데이터 마스킹 규칙

데이터 마스킹을 사용하면 쿼리를 실행하는 사용자의 역할에 따라 쿼리 런타임 시 열에 데이터 마스킹 규칙이 적용됩니다. 마스킹은 쿼리와 관련된 다른 작업보다 우선 적용됩니다. 데이터 마스킹 규칙은 열 데이터에 적용되는 데이터 마스킹 유형을 결정합니다.

다음과 같은 데이터 마스킹 규칙을 사용할 수 있습니다.

커스텀 마스킹 루틴. 열에 사용자 정의 함수(UDF)를 적용한 후 열 값을 반환합니다. 마스킹 규칙을 관리하려면 루틴 권한이 필요합니다. 이 규칙은 기본적으로 STRUCT 데이터 유형을 제외한 모든 BigQuery 데이터 유형을 지원합니다. 하지만 STRING 및 BYTES 이외의 데이터 유형에 대한 지원은 제한됩니다. 출력은 정의된 함수에 따라 다릅니다.

커스텀 마스킹 루틴에 UDF를 만드는 방법에 대한 자세한 내용은 커스텀 마스킹 루틴 만들기를 참조하세요.
날짜 연도 마스크. 값을 연도로 자른 후 열의 값을 반환하여 값에서 연도가 아닌 모든 부분을 연도의 시작으로 설정합니다. 이 규칙은 DATE, DATETIME, TIMESTAMP 데이터 유형을 사용하는 열에만 사용할 수 있습니다. 예를 들면 다음과 같습니다.

유형 원본 마스킹됨

DATE 2030-07-17 2030-01-01

DATETIME 2030-07-17T01:45:06 2030-01-01T00:00:00

TIMESTAMP 2030-07-17 01:45:06 2030-01-01 00:00:00

참고: 잘림은 UTC 시간대에 따라 발생합니다. 이를 변경하려면 @@time_zone 시스템 변수를 사용하여 기본 시간대를 조정합니다.

유형	원본	마스킹됨
`DATE`	2030-07-17	2030-01-01
`DATETIME`	2030-07-17T01:45:06	2030-01-01T00:00:00
`TIMESTAMP`	2030-07-17 01:45:06	2030-01-01 00:00:00

기본 마스킹 값 열의 데이터 유형에 따라 열의 기본 마스킹 값을 반환합니다. 열의 값은 숨기고 데이터 유형을 공개하려는 경우에 사용합니다. 이러한 데이터 마스킹 규칙이 열에 적용되면 마스킹된 리더 액세스 권한이 있는 사용자의 쿼리 JOIN 작업에 유용하지 않을 수 있습니다. 이는 기본값이 테이블을 조인할 때 유용할 만큼 고유하지 않기 때문입니다.

다음 표에서는 각 데이터 유형의 기본 마스킹 값을 보여줍니다.

데이터 유형	기본 마스킹 값
`STRING`	""
`BYTES`	b''
`INTEGER`	0
`FLOAT`	0.0
`NUMERIC`	0
`BOOLEAN`	`FALSE`
`TIMESTAMP`	1970-01-01 00:00:00 UTC
`DATE`	1970-01-01
`TIME`	00:00:00
`DATETIME`	1970-01-01T00:00:00
`GEOGRAPHY`	POINT(0 0)
`BIGNUMERIC`	0
`ARRAY`	[]
`STRUCT`	NOT_APPLICABLE 정책 태그는 `STRUCT` 데이터 유형을 사용하는 열에 적용할 수 없지만 이러한 열의 리프 필드와 연결될 수 있습니다.
`JSON`	null

이메일 마스크. 유효한 이메일의 사용자 이름을 XXXXX로 바꾼 후 열 값을 반환합니다. 열의 값이 유효한 이메일 주소가 아닌 경우 SHA-256 해시 함수를 통해 실행된 열의 값이 반환됩니다. 이 규칙은 STRING 데이터 유형을 사용하는 열에만 사용할 수 있습니다. 예를 들면 다음과 같습니다.

원본 마스킹됨

abc123@gmail.com XXXXX@gmail.com

randomtext jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=

test@gmail@gmail.com Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=
처음 4자(영문 기준). 열 값의 처음 4자를 반환하고 나머지 문자열을 XXXXX로 바꿉니다. 열 값의 길이가 4자 이하면 SHA-256 해시 함수를 통해 실행한 후 열 값을 반환합니다. 이 규칙은 STRING 데이터 유형을 사용하는 열에만 사용할 수 있습니다.
해시(SHA-256) SHA-256 해시 함수를 통해 실행된 열의 값을 반환합니다. 최종 사용자가 쿼리의 JOIN 작업에서 이 열을 사용할 수 있게 하기 위해 사용합니다. 이 규칙은 STRING 또는 BYTES 데이터 유형을 사용하는 열에만 사용할 수 있습니다.

데이터 마스킹에 사용된 SHA-256 함수는 유형 보존이므로 반환되는 해시 값의 데이터 유형은 열 값과 동일합니다. 예를 들어 STRING 열 값의 해시 값에는 STRING 데이터 유형도 있습니다.

중요: SHA-256은 확정적 해싱 함수입니다. 초기 값은 항상 동일한 해시 값으로 확인됩니다. 그러나 암호화 키는 필요하지 않습니다. 이를 통해 악의적인 행위자는 SHA-256 알고리즘을 통해 가능한 모든 원래 값을 실행하고 데이터 마스킹에서 반환된 해시와 일치하는 해시를 생성하는 값을 확인함으로써 무차별 대입 공격을 사용하여 원래 값을 결정할 수 있습니다.
마지막 4자(영문 기준). 열 값의 마지막 4자를 반환하고 나머지 문자열을 XXXXX로 바꿉니다 열 값의 길이가 4자 이하면 SHA-256 해시 함수를 통해 실행한 후 열 값을 반환합니다. 이 규칙은 STRING 데이터 유형을 사용하는 열에만 사용할 수 있습니다.
무효화. 열 값 대신 NULL을 반환합니다. 열의 값과 데이터 유형을 모두 숨기려면 이를 사용하세요. 이러한 데이터 마스킹 규칙이 열에 적용되면 마스킹된 리더 액세스 권한이 있는 사용자의 쿼리 JOIN 작업에 유용하지 않을 수 있습니다. 이는 NULL 값이 테이블을 조인할 때 유용할 만큼 고유하지 않기 때문입니다.

원본	마스킹됨
`abc123@gmail.com`	`XXXXX@gmail.com`
`randomtext`	`jQHDyQuj7vJcveEe59ygb3Zcvj0B5FJINBzgM6Bypgw=`
`test@gmail@gmail.com`	`Qdje6MO+GLwI0u+KyRyAICDjHbLF1ImxRqaW08tY52k=`

데이터 마스킹 규칙 계층 구조

정책 태그에 대해 최대 9개의 데이터 정책을 구성할 수 있으며, 이때 각 정책에는 서로 다른 데이터 마스킹 규칙이 연결되어 있습니다. 이러한 정책 중 하나는 열 수준 액세스 제어 설정용으로 예약되어 있습니다. 따라서 사용자가 속한 그룹을 기준으로 여러 데이터 정책 중 일부를 사용자 쿼리의 열에 적용할 수 있습니다. 이 경우 BigQuery는 다음 계층 구조에 따라 적용할 데이터 마스킹 규칙을 선택합니다.

커스텀 마스킹 루틴
해시(SHA-256)
이메일 마스크
마지막 4자(영문 기준)
처음 4자(영문 기준)
날짜 연도 마스크
기본 마스킹 값
무효화

예를 들어 사용자 A는 직원과 회계 그룹의 구성원입니다. 사용자 A는 confidential 정책 태그가 적용된 sales_total 필드가 포함된 쿼리를 실행합니다. confidential 정책 태그에는 2개의 데이터 정책이 연결되어 있습니다. 하나는 직원 역할을 주 구성원으로 가지고 무효화 데이터 마스킹 규칙을 적용하며, 다른 하나는 회계 역할을 주 구성원으로 가지고 해시(SHA-256) 데이터 마스킹 규칙을 적용합니다. 이 경우 해시(SHA-256) 데이터 마스킹 규칙은 무효화 데이터 마스킹 규칙보다 우선적으로 처리되므로 해시(SHA-256) 규칙이 사용자 A의 쿼리에 있는 sales_total 필드 값에 적용됩니다.

그림 3은 이 시나리오를 보여줍니다.

사용자가 있는 그룹으로 인해 무효화 및 해시(SHA-256) 데이터 마스킹 규칙 적용 간에 충돌이 발생하는 경우 해시(SHA-256) 데이터 마스킹 규칙이 우선적으로 적용됩니다.

그림 3. 데이터 마스킹 규칙 우선순위

역할 및 권한

분류 및 정책 태그를 관리하는 역할

분류 및 정책 태그를 만들고 관리하려면 Data Catalog 정책 태그 관리자 역할이 필요합니다.

역할/ID 권한 설명

역할/ID	권한	설명
Data Catalog 정책 태그 관리자/`datacatalog.categoryAdmin`	`datacatalog.categories.getIamPolicy` `datacatalog.categories.setIamPolicy` `datacatalog.taxonomies.create` `datacatalog.taxonomies.delete` `datacatalog.taxonomies.get` `datacatalog.taxonomies.getIamPolicy` `datacatalog.taxonomies.list` `datacatalog.taxonomies.setIamPolicy` `datacatalog.taxonomies.update` `resourcemanager.projects.get` `resourcemanager.projects.list`	프로젝트 수준에서 적용됩니다. 이 역할은 다음을 수행할 수 있는 권한을 부여합니다. 분류 및 정책 태그를 생성, 읽기, 업데이트, 삭제합니다. 정책 태그에 IAM 정책을 가져오고 설정합니다.

Data Catalog 정책 태그 관리자/datacatalog.categoryAdmin

datacatalog.categories.getIamPolicy
datacatalog.categories.setIamPolicy
datacatalog.taxonomies.create
datacatalog.taxonomies.delete
datacatalog.taxonomies.get
datacatalog.taxonomies.getIamPolicy
datacatalog.taxonomies.list
datacatalog.taxonomies.setIamPolicy
datacatalog.taxonomies.update
resourcemanager.projects.get
resourcemanager.projects.list

프로젝트 수준에서 적용됩니다.

이 역할은 다음을 수행할 수 있는 권한을 부여합니다.

분류 및 정책 태그를 생성, 읽기, 업데이트, 삭제합니다.
정책 태그에 IAM 정책을 가져오고 설정합니다.

데이터 정책을 만들고 관리하는 역할

데이터 정책을 만들고 관리하려면 다음 BigQuery 역할 중 하나가 필요합니다.

역할/ID 권한 설명

역할/ID	권한	설명
BigQuery 관리자/`bigquery.admin` BigQuery 데이터 소유자/`bigquery.dataOwner`	`bigquery.dataPolicies.create` `bigquery.dataPolicies.delete` `bigquery.dataPolicies.get` `bigquery.dataPolicies.getIamPolicy` `bigquery.dataPolicies.list` `bigquery.dataPolicies.setIamPolicy` `bigquery.dataPolicies.update`	`bigquery.dataPolicies.create` 및 `bigquery.dataPolicies.list` 권한은 프로젝트 수준에서 적용됩니다. 다른 권한은 데이터 정책 수준에서 적용됩니다. 이 역할은 다음을 수행할 수 있는 권한을 부여합니다. 데이터 정책을 생성, 읽기, 업데이트, 삭제합니다. 데이터 정책의 IAM 정책을 가져오고 설정합니다.

BigQuery 관리자/bigquery.admin

BigQuery 데이터 소유자/bigquery.dataOwner

bigquery.dataPolicies.create
bigquery.dataPolicies.delete
bigquery.dataPolicies.get
bigquery.dataPolicies.getIamPolicy
bigquery.dataPolicies.list
bigquery.dataPolicies.setIamPolicy
bigquery.dataPolicies.update

bigquery.dataPolicies.create 및 bigquery.dataPolicies.list 권한은 프로젝트 수준에서 적용됩니다. 다른 권한은 데이터 정책 수준에서 적용됩니다.

이 역할은 다음을 수행할 수 있는 권한을 부여합니다.

데이터 정책을 생성, 읽기, 업데이트, 삭제합니다.
데이터 정책의 IAM 정책을 가져오고 설정합니다.

또한 여러 Data Catalog 사전 정의된 역할에서 얻을 수 있는 datacatalog.taxonomies.get 권한이 필요합니다.

정책 태그를 열에 연결하는 역할

정책 태그를 열에 연결하려면 datacatalog.taxonomies.get 및 bigquery.tables.setCategory 권한이 필요합니다. datacatalog.taxonomies.get은 Data Catalog 정책 태그 관리자 역할과 뷰어 역할에 포함되어 있습니다. bigquery.tables.setCategory는 BigQuery 관리자(roles/bigquery.admin) 및 BigQuery 데이터 소유자(roles/bigquery.dataOwner) 역할에 포함되어 있습니다.

마스킹된 데이터를 쿼리하는 역할

데이터 마스킹이 적용된 열의 데이터를 쿼리하려면 BigQuery 마스킹된 리더 역할이 필요합니다.

역할/ID 권한 설명

역할/ID	권한	설명
마스킹된 리더/`bigquerydatapolicy.maskedReader`	`bigquery.dataPolicies.maskedGet`	데이터 정책 수준에서 적용됩니다. 이 역할은 데이터 정책과 연결된 열의 마스킹된 데이터를 볼 수 있는 권한을 부여합니다. 또한 사용자에게 테이블을 쿼리할 수 있는 적절한 권한이 있어야 합니다. 자세한 내용은 필수 권한을 참조하세요.

마스킹된 리더/bigquerydatapolicy.maskedReader

bigquery.dataPolicies.maskedGet

데이터 정책 수준에서 적용됩니다.

이 역할은 데이터 정책과 연결된 열의 마스킹된 데이터를 볼 수 있는 권한을 부여합니다.

또한 사용자에게 테이블을 쿼리할 수 있는 적절한 권한이 있어야 합니다. 자세한 내용은 필수 권한을 참조하세요.

마스킹된 리더 및 세분화된 권한의 리더 역할이 상호작용하는 방법

데이터 마스킹은 열 수준 액세스 제어를 기반으로 빌드됩니다. 특정 열의 경우 마스킹된 데이터를 읽을 수 있는 BigQuery 마스킹된 리더 역할을 보유한 일부 사용자, 마스킹되지 않은 데이터를 읽을 수 있는 Data Catalog 세분화된 리더 역할을 보유한 일부 사용자, 둘 다 가진 사용자, 어느 쪽도 가지고 있지 않은 일부 사용자가 있을 수 있습니다. 이러한 역할은 다음과 같이 상호작용합니다.

세분화된 권한의 리더 역할과 마스킹된 리더 역할이 모두 있는 사용자: 사용자에게 표시되는 내용은 정책 태그 계층 구조에서 각 역할이 부여된 위치에 따라 다릅니다. 자세한 내용은 정책 태그 계층 구조의 승인 상속을 참조하세요.
세분화된 권한의 리더 역할이 있는 사용자: 마스킹 해제된(가려지지 않은) 열 데이터를 볼 수 있습니다.
마스킹된 리더 역할이 있는 사용자: 마스킹된(가려진) 열 데이터를 볼 수 있습니다.
역할이 없는 사용자: 권한 거부되었습니다.

테이블에 보안 및/또는 마스킹된 열이 있는 경우 해당 테이블에서 SELECT * FROM 문을 실행하려면 사용자가 위의 모든 열에서 마스킹된 리더 또는 세분화된 권한의 리더 역할이 부여된 적절한 그룹의 구성원이어야 합니다.

이러한 역할이 부여되지 않은 사용자는 대신 SELECT 문에서 액세스 권한이 있는 열만 지정하거나 SELECT * EXCEPT (restricted_columns) FROM을 사용하여 보안 또는 마스킹된 열을 제외해야 합니다.

정책 태그 계층 구조의 승인 상속

역할은 열과 연결된 정책 태그부터 평가되며, 사용자에게 적절한 권한이 있는지 또는 정책 태그 계층 구조의 최상위에 도달했는지 확인될 때까지 해당 분류의 각 오름차순으로 확인됩니다.

예를 들어 그림 4에 표시된 정책 태그와 데이터 정책 구성을 살펴보겠습니다.

더 높은 수준의 분류에서 마스킹된 리더 역할이 부여되고 하위 수준의 분류에서 세분화된 권한의 리더 역할이 부여되는 경우 사용자 액세스를 평가합니다.

그림 4. 정책 태그 및 데이터 정책 구성

Financial 정책 태그로 주석 처리된 테이블 열과 ftes@example.com 및 analysts@example.com 그룹 모두의 구성원인 사용자가 있습니다. 이 사용자가 주석 처리된 열이 포함된 쿼리를 실행하면 정책 태그 분류에 정의된 계층 구조에 따라 액세스 권한이 결정됩니다. Financial 정책 태그에 의해 Data Catalog 세분화된 권한의 리더 역할이 사용자에게 부여되었으므로 쿼리는 마스킹되지 않은 열 데이터를 반환합니다.

ftes@example.com 역할의 구성원인 다른 사용자만 주석 처리된 열이 포함된 쿼리를 실행하는 경우 이 쿼리에서 SHA-256 알고리즘을 사용하여 해시된 열 데이터를 반환하는 데, 그 이유는 사용자에게 Financial 정책 태그의 상위 요소인 Confidential 정책 태그에서 BigQuery 마스크 리더 역할을 부여하기 때문입니다.

이러한 역할의 구성원이 아닌 사용자가 주석 처리된 열을 쿼리하려 하면 액세스 거부 오류가 발생합니다.

앞의 시나리오와 반대로 그림 5에 표시된 정책 태그 및 데이터 정책 구성을 사용합니다.

더 높은 수준의 분류에서 세분화된 권한의 리더 역할이 부여되고 하위 수준의 분류에서 마스킹된 리더 역할이 부여되는 경우 사용자 액세스를 평가합니다.

그림 5. 정책 태그 및 데이터 정책 구성

그림 4와 동일한 상황이지만 사용자에게 정책 태그 계층 구조의 상위 수준에서 세분화된 권한의 리더 역할과 정책 태그 계층의 하위 수준에서 마스크된 리더 역할이 부여됩니다. 따라서 쿼리가 이 사용자의 마스킹된 열 데이터를 반환합니다. 이는 사용자에게 태그 계층 구조의 상위에 있는 세분화된 권한의 리더 역할이 부여된 경우에도 발생하는 데, 그 이유는 서비스가 정책 태그 계층 구조를 오름차순으로 이동할 때 처음으로 할당된 역할을 사용하여 사용자 액세스를 확인하기 때문입니다.

단일 데이터 정책을 만들고 여러 수준의 정책 태그 계층 구조에 적용하려는 경우 해당 정책을 적용해야 하는 최상위 계층 수준을 나타내는 정책 태그에 데이터 정책을 설정할 수 있습니다. 예를 들어 다음 구조로 분류를 수행합니다.

정책 태그 1
- 정책 태그 1a
  - 정책 태그 1ai
- 정책 태그 1b
  - 정책 태그 1bi
  - 정책 태그 1bii

데이터 정책을 이러한 모든 정책 태그에 적용하려면 정책 태그 1에 데이터 정책을 설정합니다. 데이터 정책을 정책 태그 1b 및 하위 요소에 적용하려면 정책 태그 1b에 데이터 정책을 설정합니다.

호환되지 않는 기능으로 데이터 마스킹

데이터 마스킹과 호환되지 않는 BigQuery 기능을 사용하면 서비스가 마스킹된 열을 보안 열로 처리하고, Data Catalog 세분화된 권한의 리더 역할이 있는 사용자에게만 액세스 권한을 부여합니다.

예를 들어 그림 6에 표시된 정책 태그와 데이터 정책 구성을 살펴보겠습니다.

이 열과 연결된 정책 태그는 사용자에게 마스킹되지 않은 데이터에 액세스할 권한이 있는지 확인하기 위해 평가됩니다.

그림 6. 정책 태그 및 데이터 정책 구성

Financial 정책 태그로 주석이 달린 테이블 열과 analytics@example.com 그룹의 구성원인 사용자가 있습니다. 이 사용자가 호환되지 않는 기능 중 하나를 통해 주석 처리된 열에 액세스하려 하면 액세스 거부 오류가 발생합니다. 이는 해당 기능들이 Financial 정책 태그에 의해 BigQuery 마스킹된 리더를 부여 받지만 Data Catalog 세분화된 권한의 리더 역할이 있어야 하기 때문입니다. 서비스가 이미 사용자에게 적용 가능한 역할을 결정했으므로 추가적인 권한을 위한 정책 태그 계층 구조를 계속 확인하지 않습니다.

출력이 있는 데이터 마스킹 예시

태그, 주 구성원, 역할이 함께 작동하는 방식을 확인하려면 이 예시를 살펴보세요.

example.com에서 기본 액세스는 data-users@example.com 그룹을 통해 부여됩니다. BigQuery 데이터에 대한 일반 액세스 권한이 필요한 모든 직원이 이 그룹의 구성원이며 BigQuery 마스킹된 리더 역할과 테이블에서 읽는 데 필요한 모든 권한이 할당됩니다.

직원은 작업에 필요한 보안 또는 마스킹된 열에 대한 액세스를 제공하는 추가 그룹에 할당됩니다. 이러한 추가 그룹의 모든 구성원은 data-users@example.com의 구성원이기도 합니다. 그림 7에서 이러한 그룹이 적절한 역할과 어떻게 연결되어 있는지 확인할 수 있습니다.

example.com의 정책 태그 및 데이터 정책

그림 7. example.com의 정책 태그 및 데이터 정책

그런 다음 그림 8과 같이 정책 태그가 테이블 열과 연결됩니다.

테이블 열과 연결된 Example.com 정책 태그

그림 8. 테이블 열과 연결된 Example.com 정책 태그

태그가 이 열과 연결된 것으로 가정하고 SELECT * FROM Accounts;를 실행하면 다른 그룹에 다음과 같은 결과가 발생합니다.

data-users@example.com: 이 그룹에는 PII 및 Confidential 정책 태그 모두에 대한 BigQuery 마스킹된 리더 역할이 부여됩니다. 다음과 같은 결과가 반환됩니다.

SSN	우선순위	생성일	이메일
NULL	""	1983년 3월 8일	NULL
NULL	""	2009년 12월 29일	NULL
NULL	""	2021년 7월 14일	NULL
NULL	""	1997년 5월 5일	NULL

accounting@example.com: 이 그룹에는 SSN 정책 태그에 대한 Data Catalog 세분화된 권한의 리더 역할이 부여되었습니다. 다음과 같은 결과가 반환됩니다.

SSN	우선순위	생성일	NULL
123-45-6789	""	1983년 3월 8일	NULL
234-56-7891	""	2009년 12월 29일	NULL
345-67-8912	""	2021년 7월 14일	NULL
456-78-9123	""	1997년 5월 5일	NULL

sales-exec@example.com: 이 그룹에는 Confidential 정책 태그에 대한 Data Catalog 세분화된 권한의 리더 역할이 부여되었습니다. 다음과 같은 결과가 반환됩니다.

SSN	우선순위	평생 가치	생성일	이메일
NULL	높음	90,000	1983년 3월 8일	NULL
NULL	높음	84,875	2009년 12월 29일	NULL
NULL	중간	38,000	2021년 7월 14일	NULL
NULL	적음	245	1997년 5월 5일	NULL

fin-dev@example.com: 이 그룹에는 Financial 정책 태그에 대한 BigQuery 마스킹된 리더 역할이 부여됩니다. 다음과 같은 결과가 반환됩니다.

SSN	우선순위	평생 가치	생성일	이메일
NULL	""	Zmy9vydG5q=	1983년 3월 8일	NULL
NULL	""	GhwTwq6Ynm=	2009년 12월 29일	NULL
NULL	""	B6y7dsgaT9=	2021년 7월 14일	NULL
NULL	""	Uh02hnR1sg=	1997년 5월 5일	NULL

다른 모든 사용자: 나열된 그룹 중 하나에 속하지 않는 모든 사용자에게 Data Catalog 세분화된 권한의 리더 또는 BigQuery 마스킹 리더 역할이 부여되지 않았기 때문에 액세스 거부 오류가 발생합니다. Accounts 테이블을 쿼리하려면 대신 SELECT * EXCEPT (restricted_columns) FROM Accounts에서 액세스할 수 있는 열만 지정하여 보안 또는 마스킹된 열을 제외해야 합니다.

비용 고려사항

데이터 마스킹은 처리되는 바이트 수에 간접적으로 영향을 미칠 수 있으므로 쿼리 비용에 영향을 미칠 수 있습니다. 사용자가 무효화 또는 기본 마스킹 값 규칙으로 마스킹된 열을 쿼리하면 해당 열이 전혀 스캔되지 않으므로 처리할 바이트 수가 줄어듭니다.

제한 및 한도

다음 섹션에서는 데이터 마스킹에 적용되는 제한 및 한도 카테고리에 대해 설명합니다.

데이터 정책 관리

특정 BigQuery 버전으로 생성된 예약을 사용하는 경우에는 이 기능을 사용하지 못할 수 있습니다. 각 버전에서 사용 설정된 기능에 대한 자세한 내용은 BigQuery 버전 소개를 참조하세요.
각 정책 태그에 데이터 정책을 최대 9개까지 만들 수 있습니다. 이러한 정책 중 하나는 열 수준 액세스 제어 설정용으로 예약되어 있습니다.
데이터 정책, 연결된 정책 태그, 이를 사용하는 루틴은 동일한 프로젝트에 있어야 합니다.

정책 태그

정책 태그 분류가 포함된 프로젝트는 조직에 속해야 합니다.
정책 태그 계층 구조는 다음 스크린샷과 같이 루트 노드에서 최하위 수준 하위 태그까지 최대 5개 수준일 수 있습니다.

액세스 제어 설정

분류에 정책 태그 중 하나 이상과 연결된 데이터 정책이 있으면 액세스 제어가 자동으로 적용됩니다. 액세스 제어를 사용 중지하려면 먼저 분류와 연결된 모든 데이터 정책을 삭제해야 합니다.

구체화된 뷰 및 반복되는 레코드 마스킹 쿼리

기존의 구체화된 뷰가 있는 경우 연결된 기본 테이블에 연결된 반복 레코드 마스킹 쿼리가 실패합니다. 이 문제를 해결하려면 구체화된 뷰를 삭제합니다. 다른 이유로 구체화된 뷰가 필요하다면 다른 데이터 세트에 만들면 됩니다.

파티션을 나눈 테이블에서 마스킹된 열 쿼리

파티션을 나눈 열 또는 클러스터링된 열에 데이터 마스킹이 포함된 쿼리는 지원되지 않습니다.

SQL 언어

Legacy SQL은 지원되지 않습니다.

커스텀 마스킹 루틴

커스텀 마스킹 루틴에는 다음과 같은 제한사항이 적용됩니다.

커스텀 데이터 마스킹은 STRUCT를 제외한 모든 BigQuery 데이터 유형을 지원합니다. 데이터 마스킹은 STRUCT 데이터 유형의 리프 필드에만 적용될 수 있기 때문입니다.
커스텀 마스킹 루틴을 삭제해도 이를 사용하는 모든 데이터 정책이 삭제되지는 않습니다. 그러나 삭제된 마스킹 루틴을 사용하는 데이터 정책은 빈 마스킹 규칙으로 유지됩니다. 동일한 태그가 있는 다른 데이터 정책에 대해 마스킹된 리더 역할이 있는 사용자는 마스킹된 데이터를 볼 수 있습니다. 다른 사람들에게는 Permission denied. 메시지가 표시됩니다. 빈 마스킹 규칙에 대한 댕글링 참조는 7일 후에 자동화된 프로세스를 통해 정리될 수 있습니다.

다른 BigQuery 기능과의 호환성

BigQuery API

tabledata.list 메서드와 호환되지 않습니다. tabledata.list를 호출하려면 이 메서드에서 반환되는 모든 열에 대한 전체 액세스 권한이 필요합니다. Data Catalog 세분화된 권한의 리더 역할은 적절한 액세스 권한을 부여합니다.

BigLake 테이블

호환 가능. 데이터 마스킹 정책은 BigLake 테이블에 적용됩니다.

BigQuery Storage Read API

호환 가능. 데이터 마스킹 정책은 BigQuery Storage Read API에서 적용됩니다.

BigQuery BI Engine

호환 가능. 데이터 마스킹 정책은 BI Engine에서 적용됩니다. 데이터 마스킹이 적용되는 쿼리는 BI Engine에 의해 가속화되지 않습니다. Looker Studio에서 이러한 쿼리를 사용하면 관련 보고서나 대시보드가 느려지고 비용이 증가할 수 있습니다.

BigQuery Omni

호환 가능. 데이터 마스킹 정책이 BigQuery Omni 테이블에 적용됩니다.

대조

호환되지 않음. 마스킹된 열에서는 대조가 지원되지 않습니다.

복사 작업

호환되지 않음. 소스에서 대상으로 테이블을 복사하려면 소스 테이블의 모든 열에 대한 전체 액세스 권한이 있어야 합니다. Data Catalog 세분화된 권한의 리더 역할은 적절한 액세스 권한을 부여합니다.

데이터 내보내기

호환 가능. BigQuery 마스킹된 리더 역할이 있으면 내보낸 데이터가 마스킹됩니다. Data Catalog 세분화된 권한의 리더 역할이 있으면 내보낸 데이터가 마스킹되지 않습니다.

행 수준 보안

호환 가능. 데이터 마스킹은 행 수준 보안 위에 적용됩니다. 예를 들어 location = "US"에 적용된 행 액세스 정책이 있고 location이 마스킹되면 사용자가 location = "US"인 행을 볼 수 있지만 위치 필드는 마스킹됩니다.

BigQuery에서 검색

부분적으로 호환됩니다. 데이터 마스킹이 적용된 색인이 생성된 열 또는 색인이 생성되지 않은 열에서 SEARCH 함수를 호출할 수 있습니다.

데이터 마스킹이 적용된 열에서 SEARCH 함수를 호출할 때는 액세스 수준과 호환되는 검색 기준을 사용해야 합니다. 예를 들어 해시(SHA-256) 데이터 마스킹 규칙으로 마스킹된 리더 액세스 권한이 있는 경우 SEARCH 절에 다음과 비슷한 해시 값을 사용합니다.

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "sg172y34shw94fujaweu");

세분화된 권한의 리더 액세스 권한이 있으면 다음과 비슷한 SEARCH 절에서 실제 열 값을 사용합니다.

SELECT * FROM myDataset.Customers WHERE SEARCH(Email, "jane.doe@example.com");

사용된 데이터 마스킹 규칙이 무효화 또는 기본 마스킹 값인 열에 대해 마스킹된 리더 액세스 권한이 있으면 검색이 유용하지 않을 수 있습니다. 이는 NULL 또는 ""와 같은 검색 기준으로 사용할 마스킹된 결과가 유용할 만큼 고유하지 않기 때문입니다.

데이터 마스킹이 적용된 색인이 생성된 열을 검색할 때는 열에 대한 세분화된 권한의 리더 액세스 권한이 있는 경우에만 검색 색인이 사용됩니다.

스냅샷

호환되지 않음. 테이블의 스냅샷을 만들려면 소스 테이블의 모든 열에 대한 전체 액세스 권한이 필요합니다. Data Catalog 세분화된 권한의 리더 역할은 적절한 액세스 권한을 부여합니다.

테이블 이름 변경

호환 가능. 테이블 이름 변경은 데이터 마스킹의 영향을 받지 않습니다.

시간 이동

시간 데코레이터 및 SELECT 문의 FOR SYSTEM_TIME AS OF 옵션과 모두 호환됩니다. 현재 데이터 세트 스키마의 정책 태그가 검색된 데이터에 적용됩니다.

쿼리 캐싱

부분적으로 호환됩니다. 약 24시간 동안 BigQuery가 쿼리 결과를 캐시하지만 그 전에 테이블 데이터 또는 스키마가 변경되면 캐시가 무효화됩니다. 다음 상황에서는 열에 Data Catalog 세분화된 권한의 리더 역할이 없는 사용자가 쿼리를 실행할 때 계속해서 열 데이터를 확인할 수 있습니다.

사용자에게 열에 대한 Data Catalog 세분화된 권한의 리더 역할이 부여되었습니다.
사용자가 제한된 열이 포함된 쿼리를 실행하고 해당 데이터가 캐시됩니다.
2단계의 24시간 이내에 사용자에게 BigQuery 마스킹된 리더 역할이 부여되고 Data Catalog 세분화된 권한의 리더 역할이 취소됩니다.
2단계의 24시간 이내에 사용자가 동일한 쿼리를 실행하면 캐시된 데이터가 반환됩니다.

와일드 카드 테이블 쿼리

호환되지 않음. 와일드 카드 쿼리와 일치하는 모든 테이블의 참조된 모든 열에 대한 전체 액세스 권한이 필요합니다. Data Catalog 세분화된 권한의 리더 역할은 적절한 액세스 권한을 부여합니다.

다음 단계

데이터 마스킹을 사용 설정하는 방법에 대한 단계별 안내를 참조하세요.