열 수준 액세스 제어 소개

BigQuery는 데이터의 정책 태그 또는 유형 기반 분류를 사용하여 민감한 열에 대해 세분화된 액세스 권한을 부여합니다. BigQuery 열 수준 액세스 제어를 사용하면 쿼리 시 사용자에게 적절한 액세스 권한이 있는지 확인하는 정책을 만들 수 있습니다. 예를 들어 정책을 통해 다음과 같은 액세스 검사를 시행할 수 있습니다.

TYPE_SSN을 포함하는 열을 보려면 group:high-access에 있어야 합니다.

열 수준 액세스 제어를 강화하려면 선택적으로 동적 데이터 마스킹을 사용하면 됩니다. 데이터 마스킹을 사용하면 열의 실제 값 대신 null, 기본값 또는 해시된 콘텐츠로 대체하여 민감한 정보를 마스킹할 수 있습니다.

열 수준 액세스 제어 워크플로

워크플로

열 수준에서 데이터 액세스를 제한하려면 다음 단계를 따르세요.

분류 및 정책 태그 정의. 데이터의 분류 및 정책 태그를 만들고 관리합니다. 가이드라인은 정책 태그 권장사항을 참조하세요.
BigQuery 열에 정책 태그 할당. BigQuery에서 스키마 주석을 사용하여 액세스를 제한하려는 각 열에 정책 태그를 할당합니다.
분류에 액세스 제어를 적용합니다. 액세스 제어를 적용하면 분류의 모든 정책 태그에 정의된 액세스 제한이 적용됩니다.
정책 태그에 대한 액세스 관리. Identity and Access Management(IAM) 정책을 사용하여 각 정책 태그에 대한 액세스를 제한합니다. 정책은 정책 태그에 속한 각 열에 적용됩니다.

쿼리 시 사용자가 열 데이터에 대한 액세스를 시도하면 BigQuery는 열 정책 태그와 정책을 확인하여 사용자에게 데이터 액세스 권한이 있는지 확인합니다.

태그를 지정해야 하는 항목 식별

갖고 있는 민감한 정보 유형과 정책 태그가 필요한 열을 확인하려면 Sensitive Data Protection을 사용하여 조직, 폴더 또는 프로젝트 간에 데이터에 대한 프로필을 생성하는 것이 좋습니다. 데이터 프로필은 테이블에 대한 측정항목과 메타데이터를 포함하며 민감한 정보와 고위험 데이터를 저장할 위치를 결정하는 데 도움이 됩니다. Sensitive Data Protection은 프로젝트, 테이블, 열 수준에서 이러한 측정항목을 보고합니다. 자세한 내용은 BigQuery 데이터의 데이터 프로필을 참조하세요.

다음 이미지에서는 열 데이터 프로필 목록을 보여줍니다(확대하려면 클릭). 데이터 위험도가 높은 열에는 매우 민감한 정보가 포함되며 열 수준 액세스 제어가 없을 수 있습니다. 또는 이러한 열에는 다수의 사용자가 액세스할 수 있는 중간 수준 또는 매우 민감한 정보가 포함될 수 있습니다.

사용 사례

민감한 정보를 높음 및 중간의 두 가지 카테고리로 분류해야 하는 조직이 있다고 가정해보세요.

정책 태그

열 수준 보안을 설정하려면 적절한 권한을 가진 데이터 관리자가 다음 단계를 수행하여 데이터 분류의 계층 구조를 설정합니다.

데이터 관리자가 "비즈니스 중요도"라는 분류를 만듭니다. 분류에는 노드 또는 정책 태그 높음 및 중간이 포함됩니다.
데이터 관리자가 높음 노드의 정책에 high-tier-access라는 그룹의 액세스 권한이 포함되는지 결정합니다.
데이터 관리자가 분류에서 높음 및 중간에 더 많은 노드 수준을 만듭니다. 최하위 노드는 employee_ssn 리프 노드와 같은 리프 노드입니다. 데이터 관리자가 employee_ssn 리프 노드에 대한 다른 액세스 정책을 만들 수 있습니다.
데이터 관리자가 특정 테이블 열에 정책 태그를 할당합니다. 이 예시에서 데이터 관리자는 높음 액세스 정책을 테이블의 employee_ssn 열에 할당합니다.
콘솔의 현재 스키마 페이지에서 데이터 관리자가 특정 열에 적용되는 정책 태그를 볼 수 있습니다. 이 예시에서 employee_snn 열은 높음 정책 태그 아래에 있으므로 employee_ssn의 스키마를 확인할 때 콘솔의 Policy tags 필드에 분류 이름 및 정책 태그인 Business criticality:High가 표시됩니다.

콘솔을 사용하여 정책 태그를 설정하는 방법에 대한 상세 설명은 열에 정책 태그 설정을 참조하세요.

bq update 명령어를 사용하여 정책 태그를 설정할 수도 있습니다. policyTags의 names 필드에는 높음 정책 태그 ID, projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id가 포함됩니다.
```
[
 ...
 {
   "name": "ssn",
   "type": "STRING",
   "mode": "REQUIRED",
   "policyTags": {
     "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id"]
   }
 },
 ...
]
```
bq update 명령어를 사용하여 정책 태그를 설정하는 방법에 대한 상세 설명은 열에 정책 태그 설정을 참조하세요.
참고: 열당 정책 태그 1개만 할당할 수 있습니다.
관리자는 중간 정책 태그에 대해서도 유사한 단계를 수행합니다.

이와 같이 세분화된 액세스를 통해 소수의 데이터 분류 정책 태그만 제어하여 여러 열에 대한 액세스를 관리할 수 있습니다.

이러한 단계에 대한 상세 설명은 열 수준 액세스 제어로 액세스 제한을 참조하세요.

열 수준 액세스 제어에 사용되는 역할

BigQuery 열 수준 액세스 제어에는 다음 역할이 사용됩니다.

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 관리자 역할 또는 BigQuery 데이터 소유자 역할이 필요합니다. Google Cloud 콘솔을 사용하여 분류에 대한 액세스 제어를 적용하면 서비스가 자동으로 데이터 정책을 만듭니다.

역할/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 권한이 필요합니다.

세분화된 Data Catalog 리더 역할은 보안 열의 데이터에 액세스해야 하는 사용자에게 필요합니다.

역할/ID 권한 설명

역할/ID	권한	설명
세분화된 권한의 리더/`datacatalog.categoryFineGrainedReader`	`datacatalog.categories.fineGrainedGet`	정책 태그 수준에서 적용됩니다. 이 역할은 정책 태그로 제한된 열의 콘텐츠에 액세스할 수 있는 권한을 부여합니다.

세분화된 권한의 리더/datacatalog.categoryFineGrainedReader

datacatalog.categories.fineGrainedGet

정책 태그 수준에서 적용됩니다.

이 역할은 정책 태그로 제한된 열의 콘텐츠에 액세스할 수 있는 권한을 부여합니다.

Data Catalog 역할에 대한 상세 설명은 Data Catalog Identity and Access Management(IAM)를 참조하세요. BigQuery 역할에 대한 상세 설명은 IAM으로 액세스 제어를 참조하세요.

쓰기의 영향

열 수준 액세스 제어로 보호되는 열에서 데이터를 읽으려면 열에 대한 정책 태그에서 세분화된 읽기 액세스 권한을 통해 사용자가 항상 읽기 권한을 보유해야 합니다.

적용 대상:

테이블(와일드 카드 포함)
뷰
테이블 복사

열 수준 액세스 제어로 보호되는 열의 행에 데이터를 쓰는 경우 쓰기 유형에 따라 사용자 요구사항이 달라집니다.

쓰기 작업이 insert이면 세분화된 읽기 액세스가 필요하지 않습니다. 하지만 사용자에게 세분화된 읽기 액세스 권한이 없으면 삽입된 데이터를 읽을 수 없습니다.

사용자가 INSERT SELECT 문을 실행하는 경우 쿼리된 테이블에 세분화된 권한의 리더 역할이 필요합니다.

쓰기 작업이 update, delete 또는 merge인 경우 사용자에게 읽기 열에 대한 세분화된 읽기 액세스 권한이 없으면 작업을 수행할 수 없습니다.

사용자는 로컬 파일 또는 Cloud Storage에서 데이터를 로드할 수 있습니다. 데이터를 테이블에 로드할 때 BigQuery는 대상 테이블의 열에 대한 세분화된 리더 권한을 확인하지 않습니다. 이는 데이터를 로드할 때 대상 테이블의 콘텐츠를 읽을 필요가 없기 때문입니다. 마찬가지로, 스트리밍 로드는 정책 태그를 확인하지 않으므로 스트리밍에서는 데이터를 로드할 수 있습니다. 사용자에게 세분화된 읽기 액세스 권한이 없으면 스트림에서 로드된 데이터를 읽을 수 있는 액세스 권한 역시 없습니다.

자세한 내용은 열 수준 액세스 제어로 쓰기에 미치는 영향을 참조하세요.

테이블 쿼리

사용자에게 데이터 세트 액세스 권한이 있고 세분화된 Data Catalog 리더 역할이 있는 경우 열 데이터를 사용할 수 있습니다. 사용자가 정상적으로 쿼리를 실행합니다.

사용자에게 데이터 세트 액세스 권한이 있지만 Data Catalog 세분화된 권한의 리더 역할이 없는 경우 열 데이터를 사용할 수 없습니다. 이러한 사용자가 SELECT *를 실행하면 사용자가 액세스할 수 없는 열이 나열되는 오류가 발생합니다. 오류를 해결하려면 다음 중 하나를 수행하세요.

사용자가 액세스할 수 없는 열을 제외하도록 쿼리를 수정합니다. 예를 들어 사용자가 ssn 열에 액세스할 수 없지만 나머지 열에 액세스할 수 있으면 다음 쿼리를 실행할 수 있습니다.
```
SELECT * EXCEPT (ssn) FROM ...
```
앞의 예시에서 EXCEPT 절은 ssn 열을 제외합니다.
Data Catalog 관리자에게 사용자를 관련 데이터 클래스에 Data Catalog 세분화된 권한의 리더로 추가하도록 요청합니다. 오류 메시지에는 사용자가 액세스해야 하는 정책 태그의 전체 이름이 표시됩니다.

쿼리 뷰

열 수준 보안이 뷰에 미치는 영향은 뷰가 승인된 뷰인지 여부와 상관없습니다. 두 경우 모두 열 수준 보안이 투명하게 시행됩니다.

승인된 뷰는 다음 중 하나입니다.

데이터 세트의 테이블에 액세스하도록 명시적으로 승인된 뷰입니다.
데이터 세트가 승인된 데이터 세트에 포함되어 있으므로 암묵적으로 데이터 세트에 있는 테이블에 액세스할 수 있는 뷰입니다.

자세한 내용은 승인된 뷰 및 승인된 데이터 세트를 참조하세요.

뷰가 승인된 뷰가 아닌 경우:

사용자가 뷰의 기본 테이블과 데이터 세트에 대한 IAM 액세스 권한과 뷰의 기본 테이블에 대한 열 수준 액세스 권한을 가진 경우 뷰의 열을 쿼리할 수 있습니다. 그렇지 않으면 뷰의 열을 쿼리할 수 없습니다.

뷰가 승인된 뷰인 경우:

뷰의 기본 테이블에 있는 열의 열 수준 보안만 액세스를 제어합니다. 테이블 수준 및 데이터 세트 수준의 IAM 정책(있는 경우)은 액세스를 확인하는 데 사용되지 않습니다. 사용자가 승인된 뷰의 기본 테이블에 사용된 정책 태그에 액세스할 수 있는 경우 사용자는 승인된 뷰에서 열을 쿼리할 수 있습니다.

다음 다이어그램은 뷰에 대한 액세스가 평가되는 방식을 보여줍니다.

뷰 액세스

max_staleness를 사용한 시간 이동 및 구체화된 뷰의 영향

BigQuery를 사용하면 이전 상태의 테이블을 쿼리할 수 있습니다. 이 기능을 사용하면 이전 시점의 행을 쿼리할 수 있습니다. 또한 특정 시점의 테이블을 복원할 수 있습니다.

Legacy SQL에서는 테이블 이름에 시간 데코레이터를 사용하여 이전 데이터를 쿼리합니다. GoogleSQL에서는 테이블의 FOR SYSTEM_TIME AS OF 절을 사용하여 이전 데이터를 쿼리합니다.

max_staleness 옵션을 설정한 구체화된 뷰는 비활성 간격 내에서 이전 데이터를 반환합니다. 이 동작은 BigQuery를 사용하여 삭제되거나 업데이트된 레코드를 쿼리할 수 있다는 점에서 뷰의 마지막 새로고침 시 FOR SYSTEM_TIME AS OF를 사용하는 쿼리와 유사합니다. t 시간에 테이블의 이전 데이터를 쿼리한다고 가정해 보겠습니다. 이 경우에는 다음 단계를 따르세요.

시간 t의 스키마가 테이블의 현재 스키마와 동일하거나 그 하위 집합인 경우 BigQuery는 현재 테이블의 최신 열 수준 보안을 확인합니다. 사용자가 현재 열을 읽을 수 있으면 해당 열의 이전 데이터를 쿼리할 수 있습니다. 열 수준 보안으로 보호되는 열의 민감한 정보를 삭제하거나 마스킹하기 위해 열 수준 보안은 민감한 정보가 정리 이후 구성된 시간 이동 기간 이 지난 후에만 안전하게 완화될 수 있습니다.
t 시점의 스키마가 쿼리의 열에 대한 현재 스키마와 다를 경우 쿼리가 실패합니다.

위치 고려사항

분류에 위치를 선택할 때 다음 제한사항을 고려하세요.

정책 태그

분류는 BigQuery 데이터 세트 및 테이블과 같은 리전별 리소스입니다. 분류를 만들 때는 분류의 리전 또는 위치를 지정합니다.

BigQuery를 사용할 수 있는 모든 리전의 테이블에 분류를 만들고 정책 태그를 적용할 수 있습니다. 그러나 분류의 정책 태그를 테이블 열에 적용하려면 분류와 테이블이 같은 리전 위치에 있어야 합니다.

다른 위치에 있는 테이블 열에 정책 태그를 적용할 수는 없지만 해당 위치에서 명시적으로 복제하여 다른 위치에 분류를 복사할 수 있습니다.

여러 리전 위치 간에 동일한 분류 및 정책 태그를 사용하려면 위치 간 정책 태그 관리에서 분류 복제를 자세히 알아보세요.

조직

참조는 여러 조직에서 사용할 수 없습니다. 테이블 및 열에 적용하려는 정책 태그가 동일한 조직 내에 있어야 합니다.

제한사항

특정 BigQuery 버전으로 생성된 예약을 사용하는 경우에는 이 기능을 사용하지 못할 수 있습니다. 각 버전에서 사용 설정된 기능에 대한 자세한 내용은 BigQuery 버전 소개를 참조하세요.
BigQuery는 BigLake 테이블, BigQuery 테이블, BigQuery Omni 테이블에 대해 열 수준 액세스 제어만 지원합니다.
대상 테이블로 덮어쓰면 --destination_schema 플래그를 사용하여 정책 태그가 있는 스키마를 지정하지 않는 한 기존 정책 태그가 테이블에서 삭제됩니다. 다음 예시에서는 --destination_schema를 사용하는 방법을 보여줍니다.
```
bq query --destination_table mydataset.mytable2 \
  --use_legacy_sql=false --destination_schema=schema.json \
  'SELECT * FROM mydataset.mytable1'
```
스키마 변경은 쿼리 실행과 별도의 작업에서 수행됩니다. --destination_table 플래그를 지정하여 쿼리 결과를 테이블에 쓰고 이후에 쿼리에 예외가 발생하면 스키마 변경사항을 건너뛸 수 있습니다. 이 경우 대상 테이블 스키마를 확인하고 필요한 경우 수동으로 업데이트합니다.
열에는 정책 태그를 하나만 포함할 수 있습니다.
테이블에는 최대 1,000개의 고유 정책 태그가 포함될 수 있습니다.
열 수준 액세스 제어를 사용 설정한 경우 legacy SQL을 사용할 수 없습니다. 대상 테이블에 정책 태그가 있으면 모든 legacy SQL 쿼리가 거부됩니다.
정책 태그 계층 구조는 다음 스크린샷과 같이 루트 노드에서 최하위 수준 하위 태그까지 최대 5개 수준일 수 있습니다.
분류 이름은 조직 내의 모든 프로젝트 간에 고유해야 합니다.
열 수준 또는 행 수준 액세스 제어를 사용 설정한 경우 리전 간에 테이블을 복사할 수 없습니다. 소스 테이블에 정책 태그가 있으면 리전 간 모든 테이블 사본이 거부됩니다.

가격 책정

열 수준 액세스 제어에는 BigQuery와 Data Catalog를 모두 사용해야 합니다. 이러한 제품의 가격 책정에 대해서는 다음 주제를 참조하세요.

감사 로깅

정책 태그가 있는 테이블 데이터를 읽을 때 참조된 정책 태그를 Cloud Logging에 저장합니다. 그러나 정책 태그 확인은 확인을 트리거한 쿼리와 연결되지 않습니다.

감사관은 Cloud Logging을 통해 어떤 민감한 정보 카테고리에 대해 어떤 종류의 액세스가 누구에게 있는지 이해할 수 있습니다. 자세한 내용은 감사 정책 태그를 참조하세요.

BigQuery의 로깅에 대한 상세 설명은 BigQuery 모니터링 소개를 참조하세요.

Google Cloud의 로깅에 대한 상세 설명은 Cloud Logging을 참조하세요.

다음 단계

열 수준 액세스 제어 사용에 대한 상세 설명은 열 수준 액세스 제어로 액세스 제한을 참조하세요.
정책 태그 권장사항은 BigQuery 권장사항: 정책 태그 사용을 참조하세요.