많은 조직들이 다양한 비즈니스 목적에 따라 데이터를 분석할 수 있도록 기밀 정보가 저장된 데이터 웨어하우스를 배포합니다. 이 문서는 BigQuery를 사용해서 데이터 웨어하우스를 배포 및 보호하는 데이터 엔지니어 및 보안 관리자를 대상으로 합니다. 이 문서는 다음으로 구성된 보안 청사진의 일부입니다.
Terraform 구성 및 스크립트 집합이 포함된 GitHub 저장소. Terraform 구성은 Google Cloud에서 기밀 데이터가 저장된 데이터 웨어하우스를 지원하는 환경을 설정합니다.
이 청사진을 사용하여 구현하는 아키텍처, 디자인 및 보안 제어 가이드(이 문서)
샘플 환경을 배포하는 둘러보기
이 문서에서는 다음 사항에 대해 설명합니다.
프로덕션 환경에서 데이터 웨어하우스 보안을 위해 사용할 수 있는 아키텍처 및 Google Cloud 서비스
데이터 익명화, 기밀 데이터의 차등 처리, 열 수준의 액세스 제어를 포함하여 Google Cloud에서 데이터 웨어하우스를 생성, 배포, 운영할 때 데이터 거버넌스에 대한 권장사항
이 문서에서는 Google Cloud 엔터프라이즈 기반 청사진에 설명된 대로 일련의 기본적인 보안 제어가 이미 구성되었다고 가정합니다. 이 문서는 데이터 웨어하우스에서 기밀 데이터 보호를 위해 기존 보안 제어에 추가적인 제어를 쌓을 수 있도록 도와줍니다.
데이터 웨어하우스 사용 사례
이 청사진은 다음 사용 사례를 지원합니다.
Google Cloud에서 보안 BigQuery 데이터 웨어하우스로 데이터 가져오기(이 문서)
개요
BigQuery와 같은 데이터 웨어하우스는 유용한 정보를 얻기 위해 비즈니스 데이터를 분석할 수 있도록 도와줍니다. 분석가는 데이터 웨어하우스에 저장된 비즈니스 데이터에 액세스해서 유용한 정보를 얻어냅니다. 데이터 웨어하우스에 기밀 데이터가 포함되어 있으면, 저장, 전송, 분석 중 비즈니스 데이터의 보안, 기밀성, 무결성, 가용성 보존을 위해 조치를 취해야 합니다. 이 청사진에서는 다음을 수행합니다.
- 기밀 데이터에 대한 보안 액세스 제어를 구성합니다.
- 데이터 파이프라인 보안 제어를 구성합니다.
- 서로 다른 캐릭터에 대해 적절한 책임 구분을 구성합니다.
- 기밀 데이터를 찾고 익명화하기 위한 템플릿을 설정합니다.
- 기밀 데이터 보호를 돕기 위해 적절한 보안 제어 및 로깅을 설정합니다.
- 데이터 분류 및 정책 태그를 사용해서 데이터 웨어하우스에 있는 특정 열에 대한 액세스를 제한합니다.
아키텍처
기밀 데이터 웨어하우스를 만들려면 데이터를 기밀 및 비기밀로 분류한 후 구분된 경계 안에 저장해야 합니다. 다음 이미지는 수집된 데이터를 분류, 익명화, 저장하는 방법을 보여줍니다. 또한 필요에 따라 분석용으로 기밀 데이터를 재식별화하는 방법을 보여줍니다.
이 아키텍처에는 다음과 같은 Google Cloud 서비스 및 기능 조합이 사용됩니다.
Identity and Access Management(IAM) 및 Resource Manager는 액세스를 제한하고 리소스를 분류합니다. 액세스 제어 및 리소스 계층 구조는 최소 권한의 원칙을 따릅니다.
VPC 서비스 제어는 승인, 액세스 제어, 보안 데이터 교환을 설정하여 서비스 및 리소스를 격리하는 보안 경계를 만듭니다. 경계는 다음과 같습니다.
수신 데이터를 수락(일괄 처리 또는 스트리밍)하고 익명화하는 데이터 수집 경계. 개별 시작 영역을 사용함으로써 수신 데이터로부터 나머지 워크로드를 보호할 수 있습니다.
기밀 데이터를 재식별하고 제한된 영역에 저장할 수 있는 기밀 데이터 경계.
암호화 키를 저장하고 기밀 데이터로 간주되는 항목을 정의하는 거버넌스 경계.
이러한 경계는 추가적인 액세스 제어 및 모니터링을 설정하여 수신 콘텐츠를 보호하고, 기밀 데이터를 격리시키고, 웨어하우스에 있는 실제 데이터로부터 거버넌스를 구분하기 위해 디자인되었습니다. 거버넌스에는 키 관리, Data Catalog 관리, 로깅이 포함됩니다.
Cloud Storage 및 Pub/Sub는 다음과 같이 데이터를 수신합니다.
Cloud Storage: 익명화 전 일괄 데이터를 수신하고 저장합니다. Cloud Storage는 TLS를 사용해서 전송 중 데이터를 암호화하고 기본적으로 스토리지 상태의 데이터를 암호화합니다. 암호화 키는 고객 관리 암호화 키(CMEK)입니다. Identity and Access Management, 액세스 제어 목록(ACL), 정책 문서와 같은 보안 제어를 사용해서 Cloud Storage 버킷 액세스를 보호할 수 있습니다. 지원되는 액세스 제어에 대한 자세한 내용은 액세스 제어 개요를 참조하세요.
Pub/Sub: 익명화 전 스트리밍 데이터를 수신하고 저장합니다. Pub/Sub는 CMEK와 함께 인증, 액세스 제어, 메시지 수준 암호화를 사용해서 데이터를 보호합니다.
2개의 Dataflow 파이프라인이 다음과 같이 기밀 데이터를 익명화 및 재식별화합니다.
- 첫 번째 파이프라인은 가명처리를 통해 기밀 데이터를 익명화합니다.
- 두 번째 파이프라인은 승인된 데이터가 액세스를 요구할 때 기밀 데이터를 재식별화합니다.
데이터 보호를 위해 Dataflow는 각 파이프라인에 대해 고유한 서비스 계정 및 암호화 키와 액세스 제어를 사용합니다. 백엔드 서비스로 이동하여 파이프라인 실행을 보호하기 위해 Dataflow는 Streaming Engine을 사용합니다. 자세한 내용은 Dataflow 보안 및 권한을 참조하세요.
Sensitive Data Protection은 수집 중에 기밀 데이터를 익명화합니다.
Sensitive Data Protection은 감지된 infoType 또는 레코드에 따라 구조화된 데이터 및 구조화되지 않은 데이터를 익명화합니다.
Cloud HSM은 키 암호화 키(KEK)를 호스팅합니다. Cloud HSM은 클라우드 기반의 하드웨어 보안 모듈(HSM) 서비스입니다.
Data Catalog는 수집 중 정책 태그로도 알려진 메타데이터를 사용해서 기밀 데이터를 자동으로 분류합니다. 또한 Data Catalog는 메타데이터를 사용해서 기밀 데이터 액세스를 관리합니다. 자세한 내용은 Data Catalog 개요를 참조하세요. 데이터 웨어하우스 내의 데이터 액세스를 제어하기 위해 기밀 데이터가 포함된 열에 정책 태그를 적용합니다.
BigQuery는 기밀 데이터 경계에 기밀 데이터를 저장합니다.
BigQuery는 액세스 제어, 기밀 데이터를 위한 열 수준 보안, 데이터 암호화를 포함하여 여러 보안 제어를 사용해서 콘텐츠를 보호합니다.
Security Command Center는 중앙의 Google Cloud 환경 전반에서 보안 발견 항목을 모니터링하고 검토합니다.
조직 구조
조직 리소스를 관리하고 테스트 환경을 프로덕션 환경에서 분리하기 위해 조직 리소스를 그룹화할 수 있습니다. Resource Manager를 사용하면 프로젝트, 폴더, 조직별로 리소스를 논리적으로 그룹화할 수 있습니다.
다음 다이어그램은 부트스트랩, 공통, 프로덕션, 비프로덕션(또는 스테이징), 개발 등의 여러 다른 환경을 나타내는 폴더로 나눠진 리소스 계층 구조를 보여줍니다. 청사진에서 대부분의 프로젝트는 프로덕션 폴더에 배포하고 데이터 거버넌스 프로젝트는 거버넌스에 사용되는 공통 폴더에 배포합니다.
폴더
폴더를 사용하여 프로덕션 환경 및 거버넌스 서비스를 비프로덕션 및 테스트 환경에서 격리합니다. 다음 표에서는 이 청사진에 사용되는 엔터프라이즈 기반 청사진의 폴더에 대해 설명합니다.
| 폴더 | 설명 |
|---|---|
| 프로덕션 | 테스트를 거쳐 사용할 준비가 된 클라우드 리소스가 있는 프로젝트를 포함합니다. |
| 공통 | 거버넌스 프로젝트와 같은 조직의 중앙화된 서비스를 포함합니다. |
조직의 폴더 구조에 맞게 이러한 폴더 이름을 변경할 수 있지만 폴더 구조를 비슷하게 유지하는 것이 좋습니다. 자세한 내용은 Google Cloud 엔터프라이즈 기반 청사진을 참조하세요.
프로젝트
프로젝트를 사용하여 환경의 각 부분을 격리합니다. 다음 표에서는 조직 내에 필요한 프로젝트에 대해 설명합니다. Terraform 코드를 실행할 때 이러한 프로젝트를 만듭니다. 이러한 프로젝트 이름을 변경할 수 있지만 프로젝트 구조를 비슷하게 유지하는 것이 좋습니다.
| 프로젝트 | 설명 |
|---|---|
| 데이터 수집 | 데이터를 수신하고 기밀 데이터를 익명화하기 위해 필요한 서비스를 포함합니다. |
| 거버넌스 | 키 관리, 로깅, 데이터 카탈로그 기능을 제공하는 서비스를 포함합니다. |
| 비기밀 데이터 | 익명화된 데이터를 저장하기 위해 필요한 서비스를 포함합니다. |
| 기밀 데이터 | 기밀 데이터를 저장하고 재식별화하기 위해 필요한 서비스를 포함합니다. |
이러한 프로젝트 외에도 해당 환경에는 Dataflow Flex 템플릿 작업을 호스팅하는 프로젝트가 포함되어야 합니다. Flex 템플릿 작업은 스트리밍 데이터 파이프라인에 필요합니다.
프로젝트에 역할 및 그룹 매핑
조직 내 여러 다른 사용자 그룹에 기밀 데이터 웨어하우스를 구성하는 프로젝트에 대한 액세스 권한을 부여해야 합니다. 다음 섹션에서는 생성된 프로젝트에서 사용자 그룹 및 역할 할당을 위한 청사진 권장사항에 대해 설명합니다. 조직의 기존 구조에 맞게 그룹을 맞춤설정할 수 있지만 책임 구분 및 역할 할당을 비슷하게 유지하는 것이 좋습니다.
데이터 분석가 그룹
데이터 분석가는 웨어하우스의 데이터를 분석합니다. 이 그룹은 다음 표에 설명된 것처럼 여러 다른 프로젝트의 역할이 필요합니다.
| 프로젝트 매핑 | 역할 |
|---|---|
| 데이터 수집 |
기밀 데이터 액세스가 필요한 데이터 분석가를 위한 추가 역할입니다. |
| 기밀 데이터 |
|
| 비기밀 데이터 |
|
데이터 엔지니어 그룹
데이터 엔지니어는 데이터 파이프라인 및 웨어하우스를 설정하고 유지 관리합니다. 이 그룹은 다음 표에 설명된 것처럼 여러 다른 프로젝트의 역할이 필요합니다.
| 프로젝트 매핑 | 역할 |
|---|---|
| 데이터 수집 | |
| 기밀 데이터 |
|
| 비기밀 데이터 |
|
네트워크 관리자 그룹
네트워크 관리자는 네트워크를 구성합니다. 네트워크 관리자는 일반적으로 네트워킹팀의 구성원입니다.
네트워크 관리자는 조직 수준에서 다음 역할이 필요합니다.
roles/logging.viewer
보안 관리자 그룹
보안 관리자는 액세스, 키, 방화벽 규칙, VPC 서비스 제어, Security Command Center와 같은 보안 제어를 관리합니다.
보안 관리자는 조직 수준에서 다음 역할이 필요합니다.
보안 분석가 그룹
보안 분석가는 보안 이슈 및 Sensitive Data Protection 발견 항목을 모니터링하고 대응합니다.
보안 분석가는 조직 수준에서 다음 역할이 필요합니다.
roles/cloudkms.viewerroles/logging.viewerroles/securitycenter.findingsEditor다음 Security Command Center 역할 중 하나가 필요합니다.
roles/securitycenter.findingsBulkMuteEditorroles/securitycenter.findingsMuteSetterroles/securitycenter.findingsStateSetter
필요한 보안 제어 이해
이 섹션에서는 Google Cloud 내에서 데이터 웨어하우스 보안을 위해 사용하는 보안 제어에 대해 설명합니다. 고려해야 할 중요한 보안 원칙은 다음과 같습니다.
최소 권한 원칙을 채택하여 액세스를 보호합니다.
세분화 설계 및 정책을 통해 네트워크 연결을 보호합니다.
각 서비스에 대한 구성을 보호합니다.
위험 수준에 따라 데이터를 분류 및 보호합니다.
데이터 웨어하우스를 호스팅하는 환경의 보안 요구사항을 이해합니다.
감지, 조사, 대응을 위해 충분한 모니터링 및 로깅을 구성합니다.
데이터 수집을 위한 보안 제어
데이터 웨어하우스를 만들려면 다른 Google Cloud 소스(예: 데이터 레이크)에서 데이터를 전송해야 합니다. 다음 옵션 중 하나를 사용하여 BigQuery에서 데이터를 데이터 웨어하우스에 전송할 수 있습니다.
Cloud Storage를 사용하는 일괄 작업
Pub/Sub를 사용하는 스트리밍 작업. 수집 중 데이터 보호를 위해서는 방화벽 규칙, 액세스 정책, 암호화를 사용할 수 있습니다.
네트워크 및 방화벽 규칙
Virtual Private Cloud(VPC) 방화벽 규칙은 경계로의 데이터 흐름을 제어합니다. restricted.googleapis.com 특수 도메인 이름에서의 특정 TCP 포트 443 연결을 제외하고 모든 이그레스를 거부하는 방화벽 규칙을 만듭니다. restricted.googleapis.com 도메인의 이점은 다음과 같습니다.
- 워크로드가 Google API 및 서비스와 통신할 때 비공개 Google 액세스를 사용해서 네트워크가 공격 표면을 줄이는 데 도움이 됩니다.
- VPC 서비스 제어를 지원하는 서비스만 사용하도록 보장합니다.
자세한 내용은 비공개 Google 액세스 구성을 참조하세요.
각 Dataflow 작업에 대해 개별 서브넷을 구성해야 합니다. 서브넷을 구분함으로써 익명화되는 데이터를 재식별화되는 데이터와 적절하게 분리할 수 있습니다.
데이터 파이프라인을 사용하려면 dwh-networking 모듈 저장소의 dataflow_firewall.tf 파일에 정의된 것처럼 방화벽에서 TCP 포트를 열어야 합니다. 자세한 내용은 인터넷 액세스 및 방화벽 규칙 구성을 참조하세요.
리소스가 외부 IP 주소를 사용할 수 없도록 compute.vmExternalIpAccess 조직 정책이 모두 거부로 설정됩니다.
경계 제어
아키텍처 다이어그램에 표시된 것처럼 기밀 데이터 웨어하우스에 대한 리소스를 개별 경계에 배치합니다. 여러 다른 경계의 서비스가 데이터를 공유할 수 있게 하려면 경계 브리지를 만듭니다. 경계 브리지는 보호되는 서비스가 해당 경계 외부에서 리소스를 요청할 수 있게 해줍니다. 이러한 브리지는 다음 연결을 수행합니다.
수집 중 익명화가 수행될 수 있도록 데이터 수집 프로젝트를 거버넌스 프로젝트에 연결합니다.
데이터 분석가의 요청에 따라 기밀 데이터를 재식별화할 수 있도록 비기밀 데이터 프로젝트와 기밀 데이터 프로젝트를 연결합니다.
데이터 분석가의 요청에 따라 재식별화를 수행할 수 있도록 기밀 프로젝트를 데이터 거버넌스 프로젝트에 연결합니다.
경계 브리지 외에도 이그레스 규칙을 사용하여 서비스 경계로 보호되는 리소스가 경계 외부 리소스에 액세스하도록 허용할 수 있습니다. 이 솔루션에서는 외부 프로젝트의 Cloud Storage에 있는 외부 Dataflow Flex 템플릿 작업을 가져오도록 이그레스 규칙을 구성합니다. 자세한 내용은 경계 외부 Google Cloud 리소스 액세스를 참조하세요.
액세스 정책
특정 ID(사용자 또는 서비스)만 리소스 및 데이터에 액세스할 수 있도록 IAM 그룹 및 역할을 사용 설정합니다.
특정 소스만 프로젝트에 액세스하도록 하려면 Google 조직에 대해 액세스 정책을 사용 설정합니다. 요청에 허용되는 IP 주소 범위를 지정하고 특정 사용자 또는 서비스 계정의 요청만 허용하는 액세스 정책을 만드는 것이 좋습니다. 자세한 내용은 액세스 수준 속성을 참조하세요.
수집에 대한 키 관리 및 암호화
두 수집 옵션 모두 Cloud HSM을 사용해서 CMEK를 관리합니다. 수집 중 데이터 보호를 위해 CMEK 키를 사용합니다. Sensitive Data Protection은 구성된 감지기를 사용해 기밀 데이터를 암호화하여 데이터를 추가로 보호합니다.
데이터를 수집하려면 다음 암호화 키를 사용합니다.
Dataflow 파이프라인 및 Pub/Sub 서비스에도 사용되는 수집 프로세스를 위한 CMEK 키. 일부 경우에는 수집 프로세스를 추출, 변환, 로드(ETL) 프로세스라고도 부릅니다.
Sensitive Data Protection을 사용하는 데이터 익명화 프로세스를 위해 Cloud HSM에서 래핑된 암호화 키
각각 비기밀 데이터 프로젝트의 BigQuery 웨어하우스 및 기밀 데이터 프로젝트의 웨어하우스를 위한 2개의 CMEK 키. 자세한 내용은 키 관리를 참조하세요.
키가 저장되었고 액세스하도록 제공되는 지리적 위치를 결정하는 CMEK 위치를 지정합니다. CMEK가 리소스와 동일한 위치에 있는지 확인해야 합니다. 기본적으로 CMEK는 30일마다 순환됩니다.
조직의 규정 준수 책임에 따라 Google Cloud 외부에서 자체 키를 관리해야 하는 경우 Cloud 외부 키 관리자를 사용 설정할 수 있습니다. 외부 키를 사용하는 경우 키 순환을 포함한 키 관리 활동을 수행해야 합니다.
서비스 계정 및 액세스 제어
서비스 계정은 사용자 대신 API 요청을 실행하기 위해 Google Cloud에서 사용할 수 있는 ID입니다. 서비스 계정은 사용자 ID가 서비스에 직접 액세스하지 못하게 해줍니다. 책임 분리를 허용하기 위해서는 특정 목적에 따라 여러 역할을 사용해서 서비스 계정을 만듭니다. 이러한 서비스 계정은 data-ingestion 모듈 및 confidential-data 모듈에 정의되어 있습니다. 서비스 계정은 다음과 같습니다.
기밀 데이터를 익명화하는 Dataflow 파이프라인에 대한 Dataflow 컨트롤러 서비스 계정
기밀 데이터를 재식별화하는 Dataflow 파이프라인에 대한 Dataflow 컨트롤러 서비스 계정
배치 파일에서 데이터를 수집하는 Cloud Storage 서비스 계정
스트리밍 서비스에서 데이터를 수집하는 Pub/Sub 서비스 계정
Dataflow 파이프라인을 만드는 일괄 Dataflow 작업을 실행하기 위한 Cloud Scheduler 서비스 계정
다음 표에서는 각 서비스 계정에 할당된 역할을 보여줍니다.
| 서비스 계정 | 이름 | 프로젝트 | 역할 |
|---|---|---|---|
Dataflow 컨트롤러 이 계정은 익명화에 사용됩니다. |
sa-dataflow-controller |
데이터 수집 | |
Dataflow 컨트롤러 이 계정은 재식별화에 사용됩니다. |
sa-dataflow-controller-reid |
기밀 데이터 | |
| Cloud Storage | sa-storage-writer |
데이터 수집 |
|
| Pub/Sub | sa-pubsub-writer |
데이터 수집 |
|
| Cloud Scheduler | sa-scheduler-controller |
데이터 수집 |
|
데이터 익명화
Sensitive Data Protection을 사용하여 수집 단계 중 구조화된 데이터 및 구조화되지 않은 데이터를 익명화합니다. 구조화된 데이터의 경우 필드 기반의 레코드 변환을 사용해서 데이터를 익명화합니다. 이 접근 방법의 예시는 /examples/de_identification_template/ 폴더를 참조하세요. 이 예시는 구조화된 데이터에서 신용카드 번호 및 카드 PIN을 확인합니다. 구조화되지 않은 데이터의 경우 정보 유형을 사용해서 데이터를 익명화합니다.
기밀로 태그 지정된 데이터를 익명화하기 위해서는 Sensitive Data Protection 및 Dataflow 파이프라인을 사용해서 이를 토큰화합니다. 이 파이프라인은 Cloud Storage에서 데이터를 가져오고, 이를 처리한 후 BigQuery 데이터 웨어하우스로 전송합니다.
데이터 익명화 프로세스에 대한 자세한 내용은 데이터 거버넌스를 참조하세요.
데이터 스토리지를 위한 보안 제어
BigQuery 웨어하우스에서 데이터 보호를 위해 다음 보안 제어를 구성합니다.
열 수준 액세스 제어
제한된 역할을 포함하는 서비스 계정
조직 정책
적절한 경계 브리지가 있는 기밀 프로젝트와 비기밀 프로젝트 사이의 VPC 서비스 제어 경계
암호화 및 키 관리
열 수준 액세스 제어
기밀 데이터 보호를 위해 BigQuery에서 특정 열에 대한 액세스 제어를 사용합니다. 이러한 열에서 데이터에 액세스하기 위해 데이터 분석가는 세분화된 권한의 리더 역할이 있어야 합니다.
BigQuery에서 열에 대해 액세스를 정의하기 위해서는 정책 태그를 만듭니다. 예를 들어 bigquery-confidential-data 예시 모듈에서 taxonomy.tf 파일은 다음 태그를 만듭니다.
신용카드 번호와 같은 매우 민감한 정보가 포함된 열에 대한
3_Confidential정책 태그. 이 태그에 액세스할 수 있는 사용자는2_Private또는1_Sensitive정책 태그로 태그 지정된 열에도 액세스할 수 있습니다.사용자의 이름과 같은 민감한 개인 식별 정보(PII)가 포함된 열에 대한
2_Private정책 태그. 이 태그에 액세스할 수 있는 사용자는1_Sensitive정책 태그로 태그 지정된 열에도 액세스할 수 있습니다.3_Confidential정책 태그로 태그 지정된 열에는 액세스할 수 없습니다.신용 한도와 같이 공개될 수 없는 데이터가 포함된 열에 대한
1_Sensitive정책 태그. 이 태그에 액세스할 수 있는 사용자라도2_Private또는3_Confidential정책 태그로 태그 지정된 열에 액세스할 수 없습니다.
태그 지정되지 않은 항목은 모두 데이터 웨어하우스에 액세스할 수 있는 모든 사용자에게 제공됩니다.
이러한 액세스 제어는 데이터가 재식별화된 뒤에도 사용자에게 액세스 권한이 명시적으로 부여되지 않는 한 데이터를 읽을 수 없도록 보장합니다.
제한된 역할을 포함하는 서비스 계정
승인된 사용자만 기밀 데이터를 볼 수 있도록 기밀 데이터 프로젝트에 대해 액세스를 제한해야 합니다. 이렇게 하려면 승인된 사용자가 가장해야 하는 roles/iam.serviceAccountUser 역할로 서비스 계정을 만듭니다. 서비스 계정 가장은 사용자가 서비스 계정 키를 다운로드하지 않아도 서비스 계정을 사용할 수 있게 함으로써 프로젝트의 전반적인 보안 수준을 향상시켜 줍니다. 가장은 roles/iam.serviceAccountTokenCreator 역할이 있는 승인된 사용자가 다운로드할 수 있는 단기 토큰을 만듭니다.
조직 정책
이 청사진에는 엔터프라이즈 기반 청사진에 사용되는 조직 정책 제약조건과 몇 가지 추가적인 제약조건이 포함되어 있습니다. 엔터프라이즈 기반 청사진에 사용되는 제약조건에 대한 자세한 내용은 조직 정책 제약조건을 참조하세요.
다음 표에서는 org_policies 모듈에 정의된 추가적인 조직 정책 제약조건을 설명합니다.
| 정책 | 제약조건 이름 | 권장 값 |
|---|---|---|
| 특정 물리적 위치로 리소스 배포를 제한합니다. 추가 값은 값 그룹을 참조하세요. |
gcp.resourceLocations
|
다음 중 하나입니다.in:us-locationsin:eu-locationsin:asia-locations
|
| 서비스 계정 생성 사용 중지 |
iam.disableServiceAccountCreation
|
true
|
| 프로젝트에 생성된 VM에 대해 OS 로그인을 사용 설정합니다. 자세한 내용은 조직에서 OS 로그인 관리 및 OS 로그인을 참조하세요. |
compute.requireOsLogin
|
true
|
| IP 주소를 기준으로 새 전달 규칙을 내부 전용으로 제한합니다. | compute.restrictProtocolForwardingCreationForTypes
|
INTERNAL
|
| Compute Engine 리소스가 사용할 수 있는 공유 VPC 서브네트워크 집합을 정의합니다. |
compute.restrictSharedVpcSubnetworks
|
projects/PROJECT_ID/regions/REGION/s
ubnetworks/SUBNETWORK-NAME.SUBNETWORK-NAME을 청사진에서 사용할 비공개 서브넷의 리소스 ID로 바꿉니다. |
| Cloud Logging에 대해 직렬 포트 출력 로깅을 사용 중지합니다. | compute.disableSerialPortLogging |
true |
스토리지 및 재식별화를 위한 키 관리 및 암호화
데이터를 재식별화할 수 있도록 기밀 데이터에 대해 CMEK 키를 개별적으로 관리합니다. Cloud HSM을 사용하여 키를 보호합니다. 데이터를 재식별화하려면 다음 키를 사용합니다.
재식별화 프로세스를 위해 Dataflow 파이프라인에 사용되는 CMEK 키
Sensitive Data Protection에서 데이터 익명화를 위해 사용하는 원래 암호화 키
기밀 데이터 프로젝트에서 BigQuery 웨어하우스에 대한 CMEK 키
수집에 대한 키 관리 및 암호화에서 설명한 것처럼 CMEK 배치 및 순환 기간을 지정할 수 있습니다. 조직에 필요한 경우 Cloud EKM을 사용할 수 있습니다.
운영 제어
Security Health Analytics 및 위협 감지와 같은 로깅 및 Security Command Center 프리미엄 등급 기능을 사용 설정할 수 있습니다. 이러한 제어는 다음을 수행하는 데 도움이 됩니다.
데이터에 액세스할 수 있는 사용자를 모니터링합니다.
적절한 감사가 설정되어 있는지 확인합니다.
이슈 관리 및 운영팀의 발생 가능한 이슈 대응 능력을 지원합니다.
액세스 투명성
액세스 투명성은 Google 지원 담당자가 사용자 데이터에 액세스해야 할 경우 실시간 알림을 제공합니다. 액세스 투명성 로그는 사람이 콘텐츠에 액세스할 때마다 생성되며, 지원 케이스와 같은 적절한 비즈니스 사유가 있는 Google 직원만 액세스 권한을 획득할 수 있습니다. 액세스 투명성을 사용 설정하는 것이 좋습니다.
로깅
감사 요구사항을 충족시키고 프로젝트를 확인하기 위해서는 추적하려는 서비스에 대한 데이터 로그를 사용해서 Google Cloud Observability를 구성합니다. centralized-logging 모듈은 다음 권장사항을 구성합니다.
모든 프로젝트 간에 집계된 로그 싱크를 만듭니다.
적절한 리전에 로그를 저장합니다.
로깅 싱크에 CMEK 키를 추가합니다.
프로젝트 내의 모든 서비스에 대해서 로그에는 데이터 읽기 및 쓰기에 대한 정보 및 관리자가 읽은 항목에 대한 정보가 포함되어야 합니다. 추가 로깅 권장사항은 감지 제어를 참조하세요.
알림 및 모니터링
청사진을 배포한 후에는 보안 이슈가 발생할 수 있음을 보안 운영 센터(SOC)에 알릴 수 있도록 알림을 설정할 수 있습니다. 예를 들어 알림을 사용해서 IAM 권한이 변경되었을 때 이를 보안 분석가에게 알려줄 수 있습니다. Security Command Center 알림 구성에 대한 자세한 내용은 발견 항목 알림 설정을 참조하세요. Security Command Center에서 게시되지 않는 추가 알림은 Cloud Monitoring을 사용해서 알림을 설정합니다.
추가 보안 고려사항
이 청사진의 보안 제어는 Google 사이버 보안 작업팀 및 타사 보안팀 모두의 검토를 마쳤습니다. NDA에 따라 STRIDE 스레드 모델 및 요약 평가 보고서 모두에 액세스를 요청하려면 secured-dw-blueprint-support@google.com으로 이메일을 보내세요.
이 솔루션에 설명된 보안 제어 외에도 이 솔루션 사용과 겹치고 상호작용하는 핵심 영역에서 보안 및 위험을 검토하고 관리해야 합니다. 여기에는 다음과 같은 내용이 포함되어 있습니다.
Dataflow 작업 구성, 배포, 실행을 위해 사용되는 코드
이 솔루션에 사용되는 데이터 분류 용어
데이터 웨어하우스에서 저장 및 분석하는 데이터 세트의 콘텐츠, 품질, 보안
다음을 포함하여 솔루션을 배포하는 전체 환경
- 이 솔루션에 연결하는 네트워크의 설계, 세분화, 보안
- 조직의 IAM 제어에 대한 보안 및 거버넌스
- 이 솔루션에 속하는 인프라에 대해 액세스 권한을 부여하는 작업자 및 해당 인프라에서 저장 및 관리되는 데이터에 액세스 권한이 있는 사용자에 대한 인증 및 승인 설정
총정리
이 문서에 설명된 아키텍처를 구현하려면 다음을 수행합니다.
엔터프라이즈 기반 청사진을 사용하거나 자체적으로 청사진을 배포할지 여부를 결정합니다. 엔터프라이즈 기반 청사진을 배포하지 않기로 한 경우에는 해당 환경에 비슷한 보안 기준이 설정되어 있어야 합니다.
청사진의 Readme를 검토하고 모든 기본 요건을 충족해야 합니다.
테스트 환경에서 둘러보기를 배포하여 실제로 작동하는 솔루션을 확인합니다. 테스트 프로세스 중 다음을 고려합니다.
Security Command Center를 사용해서 규정 준수 요구사항에 따라 새로 생성된 프로젝트를 스캔합니다.
BigQuery 웨어하우스에 자체 샘플 데이터를 추가합니다.
기업 내 데이터 분석가와 협력하여 기밀 데이터에 대한 액세스 권한을 테스트하고 예상한 방식으로 BigQuery 데이터와 상호작용할 수 있는지 여부를 확인합니다.
프로덕션 환경에 청사진을 배포합니다.
다음 단계
기준 보안 환경에 대한 Google Cloud 엔터프라이즈 기반 청사진 검토하기
청사진의 세부정보를 보려면 Terraform 구성 readme 참조
권장사항 및 청사진은 보안 권장사항 센터 참조