이 페이지는 Cloud Translation API를 통해 번역되었습니다.

BigQuery 데이터 웨어하우스에 CDMC 키 제어 프레임워크 구현

많은 조직들이 다양한 비즈니스 목적에 따라 데이터를 분석할 수 있도록 민감한 정보를 저장하는 클라우드 데이터 웨어하우스를 배포합니다. 이 문서에서는 서 엔터프라이즈 데이터 관리 위원회에서 관리하는 Cloud 데이터 관리 기능 (CDMC) 키 제어 프레임워크를 BigQuery 데이터 웨어하우스에 구현하는 방법을 설명합니다.

CDMC 키 관리 프레임워크는 주로 클라우드 서비스 제공업체 및 기술 제공업체를 위해 게시되었습니다. 이 프레임워크에서는 제공업체가 고객이 클라우드에서 민감한 정보를 효과적으로 관리하고 규제할 수 있도록 구현할 수 있는 14가지 주요 제어 기능을 설명합니다. 이 제어 조치는 100개 이상의 회사에서 300명 이상의 전문가가 참여한 CDMC 작업 그룹에서 작성했습니다. 프레임워크를 작성하는 동안 CDMC 작업 그룹은 존재하는 많은 법적 및 규제 요구사항을 고려했습니다.

이 BigQuery 및 Data Catalog 참조 아키텍처는 CDMC 인증 클라우드 솔루션으로 CDMC 키 제어 프레임워크에 대해 평가 및 인증되었습니다. 참조 아키텍처는 다양한 Google Cloud 서비스 및 기능과 공개 라이브러리를 사용하여 CDMC 키 제어 및 권장 자동화를 구현합니다. 이 문서에서는 BigQuery 데이터 웨어하우스에서 민감한 정보를 보호하는 데 도움이 되는 주요 제어 기능을 구현하는 방법을 설명합니다.

아키텍처

다음 Google Cloud 참조 아키텍처는 CDMC 키 제어 프레임워크 테스트 사양 v1.1.1과 일치합니다. 다이어그램의 숫자는 Google Cloud 서비스로 처리되는 주요 제어를 나타냅니다.

CDMC 아키텍처 구성요소

참조 아키텍처는 민감한 정보가 포함된 BigQuery 데이터 웨어하우스를 보호하는 데 도움이 되는 아키텍처를 제공하는 안전한 데이터 웨어하우스 청사진을 기반으로 합니다. 앞의 다이어그램에서 다이어그램 상단의 프로젝트(회색)는 보안 데이터 웨어하우스 청사진의 일부이며 데이터 거버넌스 프로젝트(파란색)에는 CDMC 키 제어 프레임워크 요구사항을 충족하기 위해 추가된 서비스가 포함되어 있습니다. CDMC 키 제어 프레임워크를 구현하기 위해 아키텍처는 데이터 거버넌스 프로젝트를 확장합니다. 데이터 거버넌스 프로젝트는 분류, 수명 주기 관리, 데이터 품질 관리와 같은 제어 기능을 제공합니다. 또한 이 프로젝트는 아키텍처를 감사하고 발견사항을 보고하는 방법을 제공합니다.

이 참조 아키텍처를 구현하는 방법에 관한 자세한 내용은 GitHub의 Google Cloud CDMC 참조 아키텍처를 참고하세요.

CDMC 핵심 관리 프레임워크 개요

다음 표에는 CDMC 키 제어 프레임워크가 요약되어 있습니다.

#	CDMC 키 제어	CDMC 제어 요구사항
1	데이터 컨트롤 규정 준수	클라우드 데이터 관리 비즈니스 사례가 정의되고 관리됩니다. 민감한 정보가 포함된 모든 데이터 애셋은 측정항목 및 자동화된 알림을 사용하여 CDMC 키 제어 규정 준수 여부를 모니터링해야 합니다.
2	마이그레이션된 데이터와 클라우드 생성 데이터 모두에 대해 데이터 소유권이 설정됨	데이터 카탈로그의 소유권 필드는 모든 민감한 정보에 대해 채워지거나 정의된 워크플로에 보고해야 합니다.
3	데이터 소싱 및 소비가 자동화에 의해 관리되고 지원됨	민감한 정보가 포함된 모든 데이터 애셋에 대해 권한이 있는 데이터 소스 및 프로비저닝 지점의 레지스터가 채워지거나 정의된 워크플로에 보고해야 합니다.
4	데이터 주권 및 해외 간 데이터 이동이 관리됨	민감한 정보의 데이터 주권 및 해외 간 이동은 정의된 정책에 따라 기록, 감사, 제어해야 합니다.
5	Data Catalog가 구현 및 사용되며 상호 운용이 가능	분류는 모든 데이터에 대해 생성 또는 수집 시 모든 환경에서 일관성 있게 자동화되어야 합니다.
6	데이터 분류가 정의되고 사용됨	분류는 모든 데이터에 대해 생성 또는 수집 시 자동화되어야 하며 항상 사용 설정되어야 합니다. 다음에 대해 분류가 자동화됩니다. PII(개인 식별 정보) 정보 민감도 분류 자료 비공개 정보(MNPI) 클라이언트 식별 정보 조직에서 정의한 분류
7	데이터 사용 권한을 관리, 적용, 추적	이 제어를 사용하려면 다음이 필요합니다. 명시적 및 정식으로 권한을 부여하기 전에는 민감한 정보에 대한 사용 권한 및 액세스 권한은 기본적으로 작성자 및 소유자에게 있습니다. 모든 민감한 정보에 대한 액세스를 추적해야 합니다.
8	윤리적인 액세스, 사용, 데이터 결과 관리	민감한 정보가 포함된 모든 데이터 공유 계약에 데이터 소비 목적이 제공되어야 합니다. 목적에는 필요한 데이터 유형과 글로벌 조직의 경우 국가 또는 법적 주체 범위가 지정되어야 합니다.
9	데이터가 보호되고 제어가 입증됨	이 제어를 사용하려면 다음이 필요합니다. 민감한 정보에는 적절한 보안 제어를 사용 설정해야 합니다. 모든 민감한 정보에 대한 보안 제어 증거를 Data Catalog에 기록해야 합니다.
10	데이터 개인 정보 보호 프레임워크가 정의되고 운영됨	데이터 보호 영향 평가(DPIA)는 관할권에 따라 모든 개인 정보에 대해 자동으로 트리거되어야 합니다.
11	데이터 수명 주기를 계획하고 관리합니다.	데이터 보관, 보관처리, 삭제는 정의된 보관 일정에 따라 관리해야 합니다.
12	데이터 품질 관리됨	가능한 경우 측정항목이 배포된 민감한 정보에 데이터 품질 측정을 사용 설정해야 합니다.
13	비용 관리 원칙 수립 및 적용됨	기술 설계 원칙이 수립되고 적용됩니다. 데이터 사용, 저장소, 이동과 직접 관련된 비용 측정항목을 카탈로그에서 사용할 수 있어야 합니다.
14	데이터 출처 및 계보 이해	모든 민감한 정보에 대해 데이터 계보 정보를 사용할 수 있어야 합니다. 이 정보에는 최소한 클라우드 환경에서 데이터가 처리되거나 생성된 소스가 포함되어야 합니다.

1. 데이터 컨트롤 규정 준수

이 제어를 사용하려면 측정항목을 사용하여 이 프레임워크의 규정 준수를 위해 모든 민감한 정보가 모니터링되는지 확인해야 합니다.

아키텍처는 각 주요 제어의 작동 범위를 보여주는 측정항목을 사용합니다. 아키텍처에는 측정항목이 정의된 기준을 충족하지 않는 경우를 나타내는 대시보드도 포함되어 있습니다.

이 아키텍처에는 데이터 애셋이 주요 관리를 충족하지 않을 때 발견사항 및 해결 권장사항을 게시하는 감지기가 포함되어 있습니다. 이러한 발견사항 및 권장사항은 JSON 형식으로 Pub/Sub 주제에 게시되어 구독자에게 배포됩니다. 티켓팅 시스템에서 자동으로 이슈가 생성되도록 내부 서비스 데스크 또는 서비스 관리 도구를 Pub/Sub 주제와 통합할 수 있습니다.

아키텍처는 Dataflow를 사용하여 발견 항목 이벤트의 예시 구독자를 만듭니다. 그러면 구독자는 데이터 거버넌스 프로젝트에서 실행되는 BigQuery 인스턴스에 저장됩니다. 제공된 여러 뷰를 사용해서 Google Cloud 콘솔에서 BigQuery Studio를 사용하여 데이터를 쿼리할 수 있습니다. Looker Studio 또는 다른 BigQuery 호환 비즈니스 인텔리전스 도구를 사용하여 보고서를 만들 수도 있습니다. 다음과 같은 보고서를 볼 수 있습니다.

마지막 실행 결과 요약
마지막 실행 결과 세부정보
마지막 실행 메타데이터
범위 내의 마지막 실행 데이터 애셋
마지막 실행 데이터 세트 통계

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 1 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

Pub/Sub는 발견 항목을 게시합니다.
Dataflow에서 BigQuery 인스턴스에 발견 항목을 로드합니다.
BigQuery는 발견 항목 데이터를 저장하고 요약 뷰를 제공합니다.
Looker Studio는 대시보드와 보고서를 제공합니다.

다음 스크린샷은 샘플 Looker Studio 요약 대시보드를 보여줍니다.

샘플 Looker Studio 요약 대시보드

다음 스크린샷은 데이터 애셋별 발견 항목의 샘플 뷰를 보여줍니다.

데이터 애셋별 발견 항목의 샘플 뷰

2. 마이그레이션된 데이터와 클라우드 생성 데이터 모두에 대해 데이터 소유권이 설정됨

이 컨트롤의 요구사항을 충족하기 위해 아키텍처는 BigQuery 데이터 웨어하우스의 데이터를 자동으로 검토하고 모든 민감한 데이터의 소유자가 식별되었음을 나타내는 데이터 분류 태그를 추가합니다.

Dataplex의 기능인 Data Catalog는 기술 메타데이터와 비즈니스 메타데이터라는 두 가지 유형의 메타데이터를 처리합니다. 지정된 프로젝트의 경우 Data Catalog는 BigQuery 데이터 세트, 테이블, 뷰를 자동으로 분류하고 기술 메타데이터를 채웁니다. 카탈로그와 데이터 애셋 간의 동기화는 거의 실시간으로 유지됩니다.

아키텍처는 Tag Engine을 사용하여 Data Catalog의 CDMC controls 태그 템플릿에 다음 비즈니스 메타데이터 태그를 추가합니다.

is_sensitive: 데이터 애셋에 민감한 정보가 포함되어 있는지 여부(데이터 분류용 제어 6 참조)
owner_name: 데이터 소유자
owner_email: 소유자의 이메일 주소입니다.

태그는 데이터 거버넌스 프로젝트의 참조 BigQuery 테이블에 저장된 기본값을 사용하여 채워집니다.

기본적으로 아키텍처는 테이블 수준에서 소유권 메타데이터를 설정하지만, 메타데이터가 열 수준에서 설정되도록 아키텍처를 변경할 수 있습니다. 자세한 내용은 Data Catalog 태그 및 태그 템플릿을 참고하세요.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 2 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

BigQuery 데이터 웨어하우스 두 개: 하나는 기밀 데이터를 저장하고 다른 하나는 데이터 애셋 소유권의 기본값을 저장합니다.
Data Catalog는 태그 템플릿 및 태그를 통해 소유권 메타데이터를 저장합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처는 민감한 정보에 소유자 이름 태그가 할당되어 있는지 확인합니다.

3. 데이터 소싱 및 소비가 자동화에 의해 관리되고 지원됨

이 제어에는 데이터 애셋 분류와 신뢰할 수 있는 소스 및 승인된 배포자의 데이터 등록이 필요합니다. 아키텍처는 Data Catalog를 사용하여 is_authoritative 태그를 CDMC controls 태그 템플릿에 추가합니다. 이 태그는 데이터 애셋의 권한 여부를 정의합니다.

Data Catalog는 기술 메타데이터와 비즈니스 메타데이터를 사용하여 BigQuery 데이터 세트, 테이블, 뷰를 분류합니다. 기술 메타데이터는 자동으로 채워지며 프로비저닝 지점의 위치인 리소스 URL을 포함합니다. 비즈니스 메타데이터는 태그 엔진 구성 파일에 정의되며 is_authoritative 태그를 포함합니다.

다음으로 예약된 실행 중에 Tag Engine은 BigQuery의 참조 테이블에 저장된 기본값을 사용하여 CDMC controls 태그 템플릿의 is_authoritative 태그를 채웁니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 3 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

BigQuery 데이터 웨어하우스 두 개: 하나는 기밀 데이터를 저장하고 다른 하나는 데이터 애셋 공신력 있는 소스의 기본값을 저장합니다.
Data Catalog는 태그를 통해 공신력 있는 소스 메타데이터를 저장합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처는 민감한 정보에 공신력 있는 소스 태그가 할당되어 있는지 확인합니다.

4. 데이터 주권 및 해외 간 데이터 이동이 관리됨

이 제어를 사용하려면 아키텍처에서 데이터 레지스트리를 검사하여 지역별 저장소 요구사항을 확인하고 사용 규칙을 적용해야 합니다. 보고서는 데이터 애셋의 지리적 위치를 설명합니다.

아키텍처는 Data Catalog를 사용하여 approved_storage_location 태그를 CDMC controls 태그 템플릿에 추가합니다. 이 태그는 데이터 저작물이 저장될 수 있는 지리적 위치를 정의합니다.

데이터의 실제 위치는 BigQuery 테이블 세부정보에 기술 메타데이터로 저장됩니다. BigQuery에서는 관리자가 데이터 세트 또는 테이블의 위치를 변경할 수 없습니다. 대신 관리자가 데이터 위치를 변경하려면 데이터 세트를 복사해야 합니다.

리소스 위치 조직 정책 서비스 제약조건은 데이터를 저장할 수 있는 Google Cloud 리전을 정의합니다. 기본적으로 아키텍처는 기밀 데이터 프로젝트에 제약조건을 설정하지만 원하는 경우 조직 또는 폴더 수준에서 제약조건을 설정할 수 있습니다. Tag Engine은 허용된 위치를 Data Catalog 태그 템플릿에 복제하고 위치를 approved_storage_location 태그에 저장합니다. Security Command Center 프리미엄 등급을 활성화하고 다른 사용자가 리소스 위치 조직 정책 서비스 제약조건을 업데이트하면 Security Command Center는 업데이트된 정책 외부에 저장된 리소스에 대한 취약점 발견 항목을 생성합니다.

Access Context Manager는 사용자가 데이터 애셋에 액세스하기 전에 있어야 하는 지리적 위치를 정의합니다. 액세스 수준을 사용하여 요청이 발생할 수 있는 리전을 지정할 수 있습니다. 그런 다음 기밀 데이터 프로젝트의 VPC 서비스 제어 경계에 액세스 정책을 추가합니다.

BigQuery는 데이터 이동을 추적하기 위해 모든 작업에 대해 전체 감사 추적을 수행하고 각 데이터 세트에 대해 쿼리합니다. 감사 추적은 BigQuery Information Schema Jobs 뷰에 저장됩니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 4 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

조직 정책 서비스는 리소스 위치 제약조건을 정의하고 적용합니다.
Access Context Manager는 사용자가 데이터에 액세스할 수 있는 위치를 정의합니다.
BigQuery 데이터 웨어하우스 두 개: 하나는 기밀 데이터를 저장하고 다른 하나는 위치 정책을 검사하는 데 사용되는 원격 함수를 호스팅합니다.
Data Catalog는 승인된 저장소 위치를 태그로 저장합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.
Cloud Logging은 감사 로그를 작성합니다.
Security Command Center는 리소스 위치 또는 데이터 액세스와 관련된 모든 발견 항목을 보고합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처에는 승인된 위치 태그에 민감한 정보의 위치가 포함되어 있는지에 대한 발견 항목이 포함됩니다.

5. Data Catalog가 구현 및 사용되며 상호 운용이 가능

이 제어를 사용하려면 데이터 카탈로그가 있어야 하며 아키텍처가 새 저작물과 업데이트된 저작물을 스캔하여 필요에 따라 메타데이터를 추가할 수 있어야 합니다.

이 제어의 요구사항을 충족하기 위해 아키텍처는 Data Catalog를 사용합니다. Data Catalog는 BigQuery 데이터 세트, 테이블, 뷰를 비롯한Google Cloud 애셋을 자동으로 로깅합니다. BigQuery에서 새 테이블을 만들면 Data Catalog에서 새 테이블의 기술 메타데이터와 스키마를 자동으로 등록합니다. BigQuery에서 테이블을 업데이트하면 데이터 카탈로그에서 거의 즉시 항목을 업데이트합니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 5 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

BigQuery 데이터 웨어하우스 두 개: 하나는 기밀 데이터를 저장하고 다른 하나는 비기밀 데이터를 저장합니다.
Data Catalog는 테이블 및 필드의 기술 메타데이터를 저장합니다.

이 아키텍처에서 기본적으로 Data Catalog는 BigQuery의 기술 메타데이터를 저장합니다. 필요한 경우 Data Catalog를 다른 데이터 소스와 통합할 수 있습니다.

6. 데이터 분류가 정의되고 사용됨

이 평가를 사용하려면 데이터가 PII인지, 클라이언트를 식별하는지, 조직이 정의하는 다른 표준을 충족하는지와 같은 민감도에 따라 데이터를 분류해야 합니다. 이 제어의 요구사항을 충족하기 위해 아키텍처는 데이터 애셋 및 민감도에 관한 보고서를 만듭니다. 이 보고서를 사용하여 민감도 설정이 올바른지 확인할 수 있습니다. 또한 새 데이터 애셋을 만들거나 기존 데이터 애셋을 변경할 때마다 데이터 카탈로그가 업데이트됩니다.

분류는 테이블 수준 및 열 수준에서 Data Catalog 태그 템플릿의 sensitive_category 태그에 저장됩니다. 분류 참조 테이블을 통해 사용 가능한 Sensitive Data Protection 정보 유형(infoType)의 순위를 높이고 더 민감한 콘텐츠의 순위를 높일 수 있습니다.

이 컨트롤의 요구사항을 충족하기 위해 아키텍처는 Sensitive Data Protection, Data Catalog, Tag Engine을 사용하여 BigQuery 테이블의 민감한 열에 다음 태그를 추가합니다.

is_sensitive: 데이터 애셋에 민감한 정보가 포함되어 있는지 여부
sensitive_category: 데이터의 카테고리. 다음 필드 중 하나를 사용해야 합니다.
- 민감한 개인 식별 정보
- 개인 식별 정보
- 민감한 개인 정보
- 개인 정보
- 공개 정보

요구사항에 맞게 데이터 카테고리를 변경할 수 있습니다. 예를 들어 자료 비공개 정보(MNPI) 분류를 추가할 수 있습니다.

Sensitive Data Protection가 데이터를 검사한 후 Tag Engine은 애셋별 DLP results 테이블을 읽어 발견 항목을 컴파일합니다. 테이블에 민감한 infoType이 하나 이상 포함된 열이 있는 경우 가장 눈에 띄는 infoType이 결정되고 민감한 열과 전체 테이블이 모두 가장 높은 순위의 카테고리로 태그됩니다. 또한 Tag Engine은 해당 정책 태그를 열에 할당하고 is_sensitive 불리언 태그를 테이블에 할당합니다.

Cloud Scheduler를 사용하여 Sensitive Data Protection 검사를 자동화할 수 있습니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 6 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

4개의 BigQuery 데이터 웨어하우스에는 다음 정보가 저장됩니다.
- 기밀 데이터
- Sensitive Data Protection 결과 정보
- 데이터 분류 참조 데이터
- 태그 내보내기 정보
Data Catalog는 분류 태그를 저장합니다.
Sensitive Data Protection는 애셋에서 민감한 infoType을 검사합니다.
Compute Engine은 각 BigQuery 데이터 세트에 대해 Sensitive Data Protection 작업을 트리거하는 검사 데이터 세트 스크립트를 실행합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처에는 다음과 같은 발견 항목이 포함됩니다.

민감한 정보에 민감한 카테고리 태그가 할당되는지 여부입니다.
민감한 정보에 열 수준 민감도 유형 태그가 할당되는지 여부입니다.

7. 데이터 사용 권한을 관리, 적용, 추적

기본적으로 크리에이터와 소유자에게만 민감한 정보에 대한 사용 권한 및 액세스 권한이 할당됩니다. 또한 이 제어를 사용하려면 아키텍처가 민감한 정보에 대한 모든 액세스를 추적해야 합니다.

이 컨트롤의 요구사항을 충족하기 위해 아키텍처는 BigQuery의 cdmc sensitive data classification 정책 태그 분류를 사용하여 BigQuery 테이블에 기밀 데이터가 포함된 열에 대한 액세스를 제어합니다. 분류에는 다음과 같은 정책 태그가 포함됩니다.

민감한 개인 식별 정보
개인 식별 정보
민감한 개인 정보
개인 정보

정책 태그를 사용하면 BigQuery 테이블에서 민감한 열을 볼 수 있는 사용자를 제어할 수 있습니다. 이 아키텍처는 Sensitive Data Protection infoType에서 파생된 민감도 분류에 이러한 정책 태그를 매핑합니다. 예를 들어 sensitive_personal_identifiable_information 정책 태그와 민감한 카테고리는 AGE, DATE_OF_BIRTH, PHONE_NUMBER, EMAIL_ADDRESS와 같은 infoType에 매핑됩니다.

이 아키텍처는 Identity and Access Management(IAM)를 사용하여 데이터에 액세스해야 하는 그룹, 사용자, 서비스 계정을 관리합니다. 테이블 수준 액세스를 위해 지정된 저작물에 IAM 권한이 부여됩니다. 또한 정책 태그를 기반으로 하는 열 수준 액세스를 사용하면 민감한 데이터 애셋에 대해 세분화된 액세스 권한을 설정할 수 있습니다. 기본적으로 사용자는 정의된 정책 태그가 있는 열에 액세스할 수 없습니다.

인증된 사용자만 데이터에 액세스할 수 있도록Google Cloud 는 Cloud Identity를 사용합니다. Cloud Identity는 기존 ID 공급업체와 제휴하여 사용자를 인증할 수 있습니다.

또한 이 제어를 사용하려면 아키텍처가 사용 권한이 정의되지 않은 데이터 애셋을 정기적으로 확인해야 합니다. Cloud Scheduler에서 관리하는 감지기는 다음 시나리오를 확인합니다.

데이터 애셋에 민감한 카테고리가 포함되어 있지만 관련 정책 태그가 없습니다.
카테고리가 정책 태그와 일치하지 않습니다.

이러한 시나리오가 발생하면 감지기는 Pub/Sub에서 게시한 발견 항목을 생성한 다음 Dataflow에 의해 BigQuery의 events 테이블에 기록됩니다. 그런 후 다음에 설명된 교정 도구를 사용하여 발견 항목을 배포할 수 있습니다. 1. 데이터 제어 규정 준수

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 7 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

BigQuery 데이터 웨어하우스는 기밀 데이터와 세분화된 액세스 제어를 위한 정책 태그 바인딩을 저장합니다.
IAM은 액세스를 관리합니다.
Data Catalog는 민감한 카테고리의 테이블 수준 및 열 수준 태그를 저장합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처는 민감한 정보에 해당하는 정책 태그가 있는지 확인합니다.

8. 윤리적인 액세스, 사용, 데이터 결과 관리

이 제어를 사용하려면 아키텍처가 승인된 소비 목적 목록을 포함하여 데이터 제공업체와 데이터 소비자 모두의 데이터 공유 계약을 저장해야 합니다. 민감한 정보의 소비 용도는 쿼리 라벨을 사용하여 BigQuery에 저장된 사용 권한에 매핑됩니다. 소비자가 BigQuery에서 민감한 정보를 쿼리할 때는 해당 사용 권한과 일치하는 유효한 목적(예: SET @@query_label = “use:3”;)을 지정해야 합니다.

아키텍처는 Data Catalog를 사용하여 CDMC controls 태그 템플릿에 다음 태그를 추가합니다. 다음 태그는 데이터 제공업체와의 데이터 공유 계약을 나타냅니다.

approved_use: 데이터 애셋의 승인된 사용 또는 사용자
sharing_scope_geography: 데이터 저작물을 공유할 수 있는 지리적 위치 목록
sharing_scope_legal_entity: 데이터 애셋을 공유할 수 있는 합의된 항목 목록입니다.

별도의 BigQuery 데이터 웨어하우스에는 다음 테이블이 포함된 entitlement_management 데이터 세트가 있습니다.

provider_agreement: 합의된 법적 주체 및 지리적 범위를 포함하여 데이터 제공업체와 체결한 데이터 공유 계약입니다. 이 데이터는 shared_scope_geography 및 sharing_scope_legal_entity 태그의 기본값입니다.
consumer_agreement: 합의된 법적 주체 및 지리적 범위를 포함하여 데이터 소비자와 체결한 데이터 공유 계약입니다. 각 계약은 데이터 애셋의 IAM 바인딩과 연결됩니다.
use_purpose: 사용 설명 및 데이터 애셋의 허용된 작업과 같은 소비 목적
data_asset: 애셋 이름, 데이터 소유자에 관한 세부정보 등 데이터 애셋에 관한 정보입니다.

BigQuery는 데이터 공유 계약을 감사하기 위해 모든 작업에 대해 전체 감사 추적을 수행하고 각 데이터 세트에 대해 쿼리합니다. 감사 추적은 BigQuery INFORMATION_SCHEMA 작업 뷰에 저장됩니다. 쿼리 라벨을 세션과 연결하고 세션 내에서 쿼리를 실행한 후에는 해당 쿼리 라벨이 있는 쿼리의 감사 로그를 수집할 수 있습니다. 자세한 내용은 BigQuery의 감사 로그 참조를 확인하세요.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 8 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

BigQuery 데이터 웨어하우스 두 개: 하나는 기밀 데이터를 저장하고 다른 하나는 제공업체 및 소비자 데이터 공유 계약과 승인된 사용 목적을 포함하는 사용 권한 데이터를 저장합니다.
Data Catalog는 공급자 데이터 공유 계약 정보를 태그로 저장합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처에는 다음과 같은 발견 항목이 포함됩니다.

entitlement_management 데이터 세트에 데이터 애셋 항목이 있는지 여부입니다.
만료된 사용 사례가 있는 민감한 테이블에서 작업을 수행할지 여부(예: consumer_agreement table의 valid_until_date가 전달됨)
잘못된 라벨 키가 있는 민감한 테이블에서 작업을 실행할지 여부
민감한 테이블에서 비어 있거나 승인되지 않은 사용 사례 라벨 값으로 작업을 실행할지 여부입니다.
민감한 테이블이 승인되지 않은 작업 메서드(예: SELECT 또는 INSERT)로 쿼리되는지 여부
민감한 데이터를 쿼리할 때 소비자가 지정한 기록된 목적이 데이터 공유 계약과 일치하는지 여부입니다.

9. 데이터가 보호되고 제어가 입증됨

이 제어를 사용하려면 민감한 정보를 보호하고 이러한 제어의 기록을 제공하는 데 도움이 되는 데이터 암호화 및 익명화를 구현해야 합니다.

이 아키텍처는 저장 데이터 암호화를 비롯한 Google 기본 보안을 기반으로 합니다. 또한 이 아키텍처를 사용하면 고객 관리 암호화 키(CMEK)를 사용하여 자체 키를 관리할 수 있습니다. Cloud KMS를 사용하면 소프트웨어 지원 암호화 키 또는 FIPS 140-2 Level 3 검증 하드웨어 보안 모듈 (HSM)로 데이터를 암호화할 수 있습니다.

이 아키텍처는 정책 태그를 통해 구성된 열 수준 동적 데이터 마스킹을 사용하고 기밀 데이터를 별도의 VPC 서비스 제어 경계 내에 저장합니다. 애플리케이션 수준의 비식별화를 추가할 수도 있습니다. 이는 온프레미스 또는 데이터 처리 파이프라인의 일부로 구현할 수 있습니다.

기본적으로 아키텍처는 HSM으로 CMEK 암호화를 구현하지만 Cloud 외부 키 관리자(Cloud EKM)도 지원합니다.

다음 표에서는 아키텍처가 us-central1 리전에 구현하는 보안 정책의 예를 설명합니다. 지역별로 서로 다른 정책을 추가하는 등 요구사항에 맞게 정책을 조정할 수 있습니다.

데이터 민감도	기본 암호화 방법	기타 허용되는 암호화 방법	기본 익명화 방법	기타 허용되는 익명화 방법
공개 정보	기본 암호화	모두	없음	모두
민감한 개인 식별 정보	HSM을 사용한 CMEK	EKM	무효화	SHA-256 해시 또는 기본 마스킹 값
개인 식별 정보	HSM을 사용한 CMEK	EKM	SHA-256 해시	무효화 또는 기본 마스킹 값
민감한 개인 정보	HSM을 사용한 CMEK	EKM	기본 마스킹 값	SHA-256 해시 또는 무효화
개인 정보	HSM을 사용한 CMEK	EKM	기본 마스킹 값	SHA-256 해시 또는 무효화

아키텍처는 Data Catalog를 사용하여 테이블 수준 CDMC controls 태그 템플릿에 encryption_method 태그를 추가합니다. encryption_method는 데이터 애셋에서 사용하는 암호화 방법을 정의합니다.

또한 아키텍처는 특정 필드에 적용되는 익명화 방법을 식별하는 security policy template 태그를 만듭니다. 이 아키텍처에는 동적 데이터 마스킹을 사용하여 적용되는 platform_deid_method가 사용됩니다. app_deid_method를 추가하고 보안 데이터 웨어하우스 청사진에 포함된 Dataflow 및 Sensitive Data Protection 데이터 수집 파이프라인을 사용하여 채울 수 있습니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 9 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

Dataflow의 선택적 인스턴스 두 개: 하나는 애플리케이션 수준 익명화를 수행하고 다른 하나는 재식별을 수행합니다.
BigQuery 데이터 웨어하우스 세 개: 하나는 기밀 데이터를 저장하고 다른 하나는 비기밀 데이터를 저장하고 세 번째는 보안 정책을 저장합니다.
Data Catalog는 암호화 및 익명화 태그 템플릿을 저장합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub에서 발견 항목을 게시했습니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처에는 다음과 같은 발견 항목이 포함됩니다.

암호화 방법 태그의 값이 지정된 민감도 및 위치에 허용되는 암호화 방법과 일치하지 않습니다.
테이블에 민감한 열이 포함되어 있지만 보안 정책 템플릿 태그에 잘못된 플랫폼 수준 익명화 방법이 포함되어 있습니다.
표에 민감한 열이 포함되어 있지만 보안 정책 템플릿 태그가 누락되었습니다.

10. 데이터 개인 정보 보호 프레임워크가 정의되고 운영됨

이 제어를 사용하려면 아키텍처에서 Data Catalog 및 분류를 검사하여 데이터 보호 영향 평가(DPIA) 보고서 또는 개인 정보 보호 영향 평가(PIA) 보고서를 만들어야 하는지 결정해야 합니다. 개인 정보 보호 평가는 지역과 규제 기관에 따라 크게 달라집니다. 영향 평가가 필요한지 확인하려면 아키텍처가 데이터 상주와 정보주체의 상주를 고려해야 합니다.

아키텍처는 Data Catalog를 사용하여 Impact assessment 태그 템플릿에 다음 태그를 추가합니다.

subject_locations: 이 저작물의 데이터에서 참조하는 피사체의 위치입니다.
is_dpia: 이 애셋에 대한 데이터 개인 정보 보호 영향 평가(DPIA)가 완료되었는지 여부입니다.
is_pia: 이 애셋에 대한 개인 정보 보호 영향 평가(PIA)가 완료되었는지 여부입니다.
impact_assessment_reports: 영향 평가 보고서가 저장된 위치에 대한 외부 링크입니다.
most_recent_assessment: 가장 최근의 영향 평가 날짜입니다.
oldest_assessment: 첫 번째 영향 평가 날짜입니다.

태그 엔진은 관리 6에 정의된 대로 각 민감한 정보 애셋에 이러한 태그를 추가합니다. 감지기는 데이터 상주, 주체 위치, 데이터 민감도(예: PII인지 여부), 필요한 영향 평가 유형(PIA 또는 DPIA)의 유효한 조합을 포함하는 BigQuery의 정책 테이블에 따라 이러한 태그의 유효성을 검증합니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 10 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

4개의 BigQuery 데이터 웨어하우스에는 다음 정보가 저장됩니다.
- 기밀 데이터
- 비기밀 데이터
- 영향 평가 정책 및 사용 권한 타임스탬프
- 대시보드에 사용되는 태그 내보내기
Data Catalog는 태그 템플릿 내의 태그에 영향 평가 세부정보를 저장합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처에는 다음과 같은 발견 항목이 포함됩니다.

민감한 정보가 영향 평가 템플릿 없이 존재합니다.
DPIA 또는 PIA 보고서에 대한 링크 없이 민감한 정보가 존재합니다.
태그가 정책 테이블의 요구사항을 충족하지 않습니다.
영향 평가가 소비자 계약 표에 있는 데이터 저작물에 대해 최근에 승인된 사용 권한보다 오래되었습니다.

11. 데이터 수명 주기가 계획되고 관리됩니다.

이 제어를 사용하려면 모든 데이터 애셋을 검사하여 데이터 수명 주기 정책이 존재하고 준수되는지 확인하는 기능이 필요합니다.

아키텍처는 Data Catalog를 사용하여 CDMC controls 태그 템플릿에 다음 태그를 추가합니다.

retention_period: 테이블을 보관하는 기간(일)
expiration_action: 보관 기간이 종료될 때 테이블을 보관처리할지 삭제할지 여부

기본적으로 이 아키텍처는 다음과 같은 보관 기간 및 만료 작업을 사용합니다.

데이터 카테고리	보관 기간(일)	만료 작업
민감한 개인 식별 정보	60	삭제
개인 식별 정보	90	보관처리
민감한 개인 정보	180	보관처리
개인 정보	180	보관처리

BigQuery용 오픈소스 애셋인 Record Manager는 위의 태그 값과 구성 파일을 기반으로 BigQuery 테이블의 삭제 및 보관처리를 자동화합니다. 삭제 절차는 테이블에 만료일을 설정하고 Record Manager 구성에 정의된 만료 시간으로 스냅샷 테이블을 만듭니다. 기본 만료 시간은 30일입니다. 소프트 삭제 기간에는 테이블을 검색할 수 있습니다. 보관 절차는 보관 기간이 지난 각 BigQuery 테이블에 대해 외부 테이블을 만듭니다. 테이블은 Parquet 형식으로 Cloud Storage에 저장되고 외부 파일에 Data Catalog의 메타데이터로 태그를 지정할 수 있는 BigLake 테이블로 업그레이드됩니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 11 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

BigQuery 데이터 웨어하우스 두 개: 하나는 기밀 데이터를 저장하고 다른 하나는 데이터 보관 정책을 저장합니다.
Cloud Storage 인스턴스 두 개: 하나는 아카이브 스토리지를 제공하고 다른 하나는 레코드를 저장합니다.
Data Catalog는 보관 기간과 작업을 태그 템플릿과 태그에 저장합니다.
Cloud Run 인스턴스 2개: 하나는 Record Manager를 실행하고 다른 하나는 감지기를 배포합니다.
다음과 같은 3개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
- 또 다른 인스턴스는 BigQuery 테이블의 삭제 및 보관처리를 자동화하는 Record Manager를 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처에는 다음과 같은 발견 항목이 포함됩니다.

민감한 저작물의 경우 보관 방법이 저작물의 위치에 대한 정책과 일치하는지 확인합니다.
민감한 저작물의 경우 보관 기간이 저작물 위치의 정책과 일치하는지 확인합니다.

12. 데이터 품질 관리됨

이 제어를 사용하려면 데이터 프로파일링 또는 사용자 정의 측정항목을 기반으로 데이터 품질을 측정할 수 있는 기능이 필요합니다.

아키텍처에는 개별 값 또는 집계 값에 대한 데이터 품질 규칙을 정의하고 특정 테이블 열에 기준점을 할당할 수 있는 기능이 포함되어 있습니다. 여기에는 정확성과 완전성을 위한 태그 템플릿이 포함되어 있습니다. Data Catalog는 각 태그 템플릿에 다음 태그를 추가합니다.

column_name: 측정항목이 적용되는 열의 이름
metric: 측정항목 또는 품질 규칙의 이름입니다.
rows_validated: 유효성 검사가 완료된 행 수입니다.
success_percentage: 이 측정항목을 충족하는 값의 비율
acceptable_threshold: 이 측정항목에 허용되는 기준
meets_threshold: 품질평가점수(success_percentage 값)가 허용되는 기준을 충족하는지 여부
most_recent_run: 측정항목 또는 품질 규칙이 실행된 최근 시간입니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 12 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

BigQuery 데이터 웨어하우스 세 개: 하나는 민감한 정보를 저장하고, 다른 하나는 민감하지 않은 데이터를 저장하고, 세 번째는 품질 규칙 측정항목을 저장합니다.
Data Catalog는 태그 템플릿 및 태그에 데이터 품질 결과를 저장합니다.
Cloud Scheduler는 Cloud Data Quality Engine이 실행되는 시점을 정의합니다.
다음과 같은 3개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
- 세 번째 인스턴스는 Cloud Data Quality Engine을 실행합니다.
Cloud Data Quality Engine은 데이터 품질 규칙을 정의하고 테이블 및 열의 데이터 품질 검사를 예약합니다.
Pub/Sub는 발견 항목을 게시합니다.

Looker Studio 대시보드에는 테이블 수준과 열 수준의 데이터 품질 보고서가 모두 표시됩니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처에는 다음과 같은 발견 항목이 포함됩니다.

데이터가 민감하지만 데이터 품질 태그 템플릿이 적용되지 않았습니다(정확성 및 완전성).
데이터가 민감하지만 민감한 열에 데이터 품질 태그가 적용되지 않았습니다.
데이터는 민감하지만 데이터 품질 결과가 규칙에 설정된 기준점 내에 있지 않습니다.
데이터는 민감하지 않으며 데이터 품질 결과가 규칙에 의해 설정된 기준점 내에 있지 않습니다.

Cloud Data Quality Engine 대신 Dataplex 데이터 품질 태스크를 구성할 수 있습니다.

13. 비용 관리 원칙 수립 및 적용됨

이 제어를 사용하려면 데이터 애셋을 검사하여 정책 요구사항 및 데이터 아키텍처를 기반으로 비용 사용량을 확인하는 기능이 필요합니다. 비용 측정항목은 스토리지 사용 및 이동에만 국한되지 않고 포괄적이어야 합니다.

아키텍처는 Data Catalog를 사용하여 cost_metrics 태그 템플릿에 다음 태그를 추가합니다.

total_query_bytes_billed: 당월 시작 이후 이 데이터 애셋에 대해 청구된 총 쿼리 바이트 수입니다.
total_storage_bytes_billed: 이번 달이 시작된 이후 이 데이터 애셋에 대해 청구된 총 스토리지 바이트 수입니다.
total_bytes_transferred: 이 데이터 애셋으로 리전 간 전송된 바이트의 합계입니다.
estimated_query_cost: 이번 달 데이터 애셋의 예상 쿼리 비용(미국 달러)입니다.
estimated_storage_cost: 이번 달 데이터 애셋의 예상 저장용량 비용(미국 달러)입니다.
estimated_egress_cost: 데이터 애셋이 대상 테이블로 사용된 이번 달의 예상 이그레스(미국 달러)입니다.

이 아키텍처는 Cloud Billing에서 cloud_pricing_export라는 BigQuery 테이블로 가격 책정 정보를 내보냅니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 13 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

Cloud Billing은 결제 정보를 제공합니다.
Data Catalog는 태그 템플릿 및 태그에 비용 정보를 저장합니다.
BigQuery는 내보낸 가격 책정 정보와 기본 제공 INFORMATION_SCHEMA 뷰를 통해 쿼리 기록 작업 정보를 저장합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처는 연관된 비용 측정항목이 없는 민감한 정보 애셋이 있는지 확인합니다.

14. 데이터 출처 및 계보 이해

이 제어를 사용하려면 소스에서 데이터 애셋의 추적 가능성을 검사하고 데이터 애셋 계보의 변경사항을 검사하는 기능이 필요합니다.

데이터 출처 및 계보에 대한 정보를 유지하기 위해 이 아키텍처는 Data Catalog에 기본 제공 데이터 계보 기능을 사용합니다. 또한 데이터 처리 스크립트는 최종 소스를 정의하고 소스를 데이터 계보 그래프에 추가 노드로 추가합니다.

이 제어의 요구사항을 충족하기 위해 아키텍처는 Data Catalog를 사용하여 ultimate_source 태그를 CDMC controls 태그 템플릿에 추가합니다. ultimate_source 태그는 이 데이터 저작물의 소스를 정의합니다.

다음 다이어그램은 이 제어에 적용되는 서비스를 보여줍니다.

제어 14 아키텍처 구성요소

이 제어의 요구사항을 충족하기 위해 아키텍처는 다음 서비스를 사용합니다.

BigQuery 데이터 웨어하우스 두 개: 하나는 기밀 데이터를 저장하고 다른 하나는 최종 소스 데이터를 저장합니다.
Data Catalog는 태그 템플릿 및 태그에 최종 소스를 저장합니다.
데이터 처리 스크립트는 Cloud Storage에서 데이터를 로드하고 최종 소스를 정의하고 소스를 데이터 계보 그래프에 추가합니다.
다음과 같은 2개의 Cloud Run 인스턴스:
- 한 인스턴스는 태그가 적용되었는지 확인하고 결과를 게시하는 Report Engine을 실행합니다.
- 또 다른 인스턴스는 보안 데이터 웨어하우스의 데이터에 태그를 지정하는 Tag Engine을 실행합니다.
Pub/Sub는 발견 항목을 게시합니다.

이 제어와 관련된 문제를 감지하기 위해 아키텍처에는 다음과 같은 검사가 포함됩니다.

민감한 정보는 최종 소스 태그 없이 식별됩니다.
민감한 정보 애셋의 계보 그래프는 채워지지 않습니다.

태그 참조

이 섹션에서는 이 아키텍처가 CDMC 키 제어 요구사항을 충족하기 위해 사용하는 태그 템플릿과 태그를 설명합니다.

테이블 수준 CDMC 제어 태그 템플릿

다음 표에는 CDMC 제어 태그 템플릿에 속하고 표에 적용되는 태그가 나와 있습니다.

태그	태그 ID	관련 키 제어
승인된 저장소 위치	`approved_storage_location`	4
승인된 사용	`approved_use`	8
데이터 소유자 이메일	`data_owner_email`	2
데이터 소유자 이름	`data_owner_name`	2
암호화 방법	`encryption_method`	9
만료 작업	`expiration_action`	11
권한 있음	`is_authoritative`	3
민감함	`is_sensitive`	6
민감한 카테고리	`sensitive_category`	6
공유 범위 지역	`sharing_scope_geography`	8
공유 범위 법인	`sharing_scope_legal_entity`	8
보관 기간	`retention_period`	11
최종 소스	`ultimate_source`	14

영향 평가 태그 템플릿

다음 표에는 영향 평가 태그 템플릿에 포함되어 있으며 테이블에 적용되는 태그가 나와 있습니다.

태그	태그 ID	관련 키 제어
피사체 위치	`subject_locations`	10
DPIA 영향 평가	`is_dpia`	10
PIA 영향 평가 여부	`is_pia`	10
영향 평가 보고서	`impact_assessment_reports`	10
최근 영향 평가	`most_recent_assessment`	10
가장 오래된 영향 평가	`oldest_assessment`	10

비용 측정항목 태그 템플릿

다음 표에는 비용 측정항목 태그 템플릿에 포함되어 있으며 표에 적용되는 태그가 나와 있습니다.

태그	탭 ID	관련 키 제어
예상 쿼리 비용	`estimated_query_cost`	13
예상 스토리지 비용	`estimated_storage_cost`	13
예상 이그레스 비용	`estimated_egress_cost`	13
청구된 총 쿼리 바이트	`total_query_bytes_billed`	13
청구된 총 스토리지 바이트 수	`total_storage_bytes_billed`	13
전송된 총 바이트	`total_bytes_transferred`	13

데이터 민감도 태그 템플릿

다음 표에는 데이터 민감도 태그 템플릿에 속하고 필드에 적용되는 태그가 나와 있습니다.

태그	태그 ID	관련 키 제어
민감한 입력란	`sensitive_field`	6
민감한 유형	`sensitive_category`	6

보안 정책 태그 템플릿

다음 표에는 보안 정책 태그 템플릿에 속하고 필드에 적용되는 태그가 나와 있습니다.

태그	태그 ID	관련 키 제어
애플리케이션 익명화 메서드	`app_deid_method`	9
플랫폼 익명화 메서드	`platform_deid_method`	9

데이터 품질 태그 템플릿

다음 표에는 완전성 및 정확성 데이터 품질 태그 템플릿에 포함되어 있고 필드에 적용되는 태그가 나와 있습니다.

태그	태그 ID	관련 키 제어
허용 가능한 임계값	`acceptable_threshold`	12
열 이름	`column_name`	12
기준 충족	`meets_threshold`	12
측정항목	`metric`	12
최근 실행	`most_recent_run`	12
확인된 행	`rows_validated`	12
성공률	`success_percentage`	12

필드 수준 CDMC 정책 태그

다음 표에는 CDMC 민감한 정보 분류 정책 태그 분류에 속하고 필드에 적용되는 정책 태그가 나와 있습니다. 이러한 정책 태그는 필드 수준 액세스를 제한하고 플랫폼 수준 데이터 비식별화를 사용 설정합니다.

데이터 분류	태그 이름	관련 키 제어
개인 식별 정보	`personal_identifiable_information`	7
개인 정보	`personal_information`	7
민감한 개인 식별 정보	`sensitive_personal_identifiable_information`	7
민감한 개인 정보	`sensitive_personal_data`	7

자동 입력된 기술 메타데이터

다음 표에는 모든 BigQuery 데이터 애셋에 대해 Data Catalog에서 기본적으로 동기화되는 기술 메타데이터가 나와 있습니다.

메타데이터	관련 키 제어
애셋 유형	—
생성 시간	—
만료 시간	11
위치	4
리소스 URL	3

다음 단계

CDMC에 대해 자세히 알아보기
보안 데이터 웨어하우스 청사진에서 사용하는 보안 제어에 관해 알아봅니다.
Data Catalog를 살펴보세요.
Dataplex자세히 알아보기
태그 엔진에 대해 자세히 알아보기
GitHub에서 Google Cloud CDMC 참조 아키텍처를 사용하여 이 솔루션 구현하기