Cloud Key Management Service 심층 탐구

저자: 소날 샤, 이일성, 월터 푸포어, 헌터 프라이어, 혼나 세겔, 드와이트 월리

감사의 말: 아드리안 시어스, 존 랜돌프, 팀 더크스, 크리스 레젝, 스탠리 매켄지, 케빈 플리본, 데이비드 헤일, 세르게이 시마코프, 데이비드 U. 리, 캐리 맥다니엘, 안톤 슈바킨, 데이브 토니슨

최종 업데이트 날짜: 2020년 4월

1. 소개

Google Cloud는 Google Cloud 고객이 데이터를 소유하고 사용 방식을 제어해야 한다는 기본 전제를 바탕으로 합니다.

Google Cloud로 데이터를 저장하면 기본적으로 저장 상태에서 암호화가 수행됩니다. Cloud Key Management Service(Cloud KMS) 플랫폼을 사용하면 저장 상태의 데이터 암호화 방법과 암호화 키 관리 방법을 더 효과적으로 제어할 수 있습니다.

Cloud KMS 플랫폼을 통해 Google Cloud 고객은 직접 사용하거나 다른 클라우드 리소스 및 애플리케이션에서 사용할 수 있도록 중앙 클라우드 서비스에서 암호화 키를 관리할 수 있습니다. 키 소스의 경우 Cloud KMS는 다음 옵션을 제공합니다.

  • Cloud KMS 소프트웨어 백엔드에서는 개발자가 직접 제어하는 대칭 또는 비대칭 키(Cloud KMS)로 데이터를 유연하게 암호화할 수 있습니다.
  • 하드웨어 키가 필요한 경우 Cloud HSM을 사용하여 대칭 키 및 비대칭 키가 오직 FIPS 140-2 Level 3 검증 하드웨어 보안 모듈(HSM)에서만 사용되도록 할 수 있습니다.
  • Cloud KMS를 사용하면 직접 생성한 키를 사용해야 할 경우 자체 암호화 키를 가져올 수 있습니다.
  • Cloud KMS에서 생성한 키를 다른 Google Cloud 서비스와 함께 사용하도록 선택할 수 있습니다. 이러한 키를 고객 관리 암호화 키(CMEK)라고 합니다. CMEK 기능을 사용하면 다른 Google Cloud 서비스의 데이터를 보호하는 데 사용하는 암호화 키를 생성, 사용, 순환, 폐기할 수 있습니다.
  • Cloud 외부 키 관리자(Cloud EKM)를 사용하면 Google Cloud 외부의 키 관리자에서 키를 만들고 관리할 수 있으며 외부 키를 사용하여 저장 데이터를 보호하도록 Cloud KMS 플랫폼을 설정할 수 있습니다. 고객 관리 암호화 키를 Cloud EKM 키와 함께 사용할 수 있습니다. Cloud EKM은 현재 이 백서에서 다루지 않습니다.

또한 Google은 API 호출에 제공된 키를 사용하여 데이터가 복호화 및 암호화되는 Compute Engine 및 Cloud Storage용 고객 제공 암호화 키(CSEK)를 지원합니다. CSEK는 이 문서에서 다루지 않습니다. 자세한 내용은 온라인 문서를 참조하세요.

'KMS 포트폴리오 다이어그램'

Cloud KMS와 관련하여 Google에서는 사용하기 쉬운 플랫폼에서 가장 광범위한 제어 옵션을 가진 확장 가능하고, 안정적이며, 우수한 솔루션을 제공하는 데 주력합니다. Cloud KMS의 5가지 설계 포인트는 다음과 같습니다.

  • 고객 관리: Cloud KMS를 사용하면 소프트웨어 및 하드웨어 암호화 키를 관리하거나 자체 키를 제공할 수 있습니다.
  • 액세스 제어 및 모니터링: Cloud KMS를 사용하면 개별 키의 권한을 관리하고 키가 사용되는 방식을 모니터링할 수 있습니다.
  • 리전성: Cloud KMS는 기본적으로 리전화를 제공합니다. 선택한 Google Cloud 리전에서만 소프트웨어 키를 만들고, 저장하고, 처리하도록 서비스가 구성됩니다.
  • 내구성: Cloud KMS는 Google Cloud에서 가장 높은 수준의 내구성 표준에 부합합니다. Cloud KMS는 데이터 손상을 방지하고 데이터가 성공적으로 복호화될 수 있는지 확인하기 위해 모든 키 자료와 메타데이터를 정기적으로 스캔하고 백업합니다.
  • 보안: Cloud KMS는 키에 대한 무단 액세스를 방지하는 강력한 보호 기능을 제공하며 ID 및 액세스 관리(IAM) 및 Cloud 감사 로그 제어와 완벽하게 통합됩니다.

이 백서에서는 일반 안정화 버전(GA)에 있는 Cloud KMS 플랫폼의 내부 작업에 중점을 둡니다. 다양한 옵션을 통해 Google Cloud에 저장하는 키 및 기타 민감한 정보를 보호할 수 있습니다. 이 백서는 Cloud KMS 아키텍처, 인프라, 기능에 대한 세부정보가 필요한 기술 분야 의사 결정권자를 대상으로 합니다. 암호화 개념과 클라우드 아키텍처에 대한 기본적인 지식을 갖추고 있으면 이 백서를 더 쉽게 이해할 수 있습니다.

2. Google의 암호화 개념 및 키 관리

이 섹션에서는 Google의 멀티 레이어 키 관리 인프라의 컨텍스트에서 키 관리에 대한 몇 가지 용어와 정의를 다룹니다.

2.1. 키, 키 버전, 키링

이 섹션에서는 키, 키 버전, 키링으로 키 그룹화에 대해 설명합니다. 다음 다이어그램은 키 그룹을 보여줍니다. 관련 정의는 다이어그램을 참조하세요.

'키 그룹의 다이어그램'

  • 키: 특정 용도로 사용하는 암호화 키를 나타내는 이름이 지정된 객체입니다. 암호화 작업에 사용되는 실제 비트인 자료는 시간이 경과함에 따라 새로운 키 버전을 만들 때 변경될 수 있습니다.

    키의 용도 및 기타 속성은 키를 사용하여 연결되고 관리됩니다. 따라서 키는 KMS 사용을 이해하는 데 가장 중요한 객체입니다.

    Cloud KMS는 비대칭 키와 대칭 키를 모두 지원합니다. 대칭 키는 GCM 모드에서 AES-256을 사용하여 일반 텍스트 블록을 암호화하는 등 일부 데이터 자료를 보호하는 데 사용됩니다. 비대칭 키는 비대칭 암호화 또는 디지털 서명 생성에 사용할 수 있습니다. 지원되는 용도 및 알고리즘은 Cloud KMS 문서에서 확인할 수 있습니다.

  • 키링: 정리를 목적으로 키를 그룹화한 것입니다. 키링은 Google Cloud 프로젝트에 속하며 특정 위치에 있습니다. 키는 키가 포함된 키링에서 IAM 정책을 상속합니다. 관련 권한을 가진 키를 키링으로 그룹화하면 각 키에 개별적으로 작업을 수행할 필요 없이 키링 수준에서 해당 키를 대상으로 권한을 부여, 취소 또는 수정할 수 있습니다. 키링은 편의성과 분류 기능을 제공하지만 키링의 그룹화가 유용하지 않을 경우 키에 대한 권한을 직접 관리할 수 있습니다.

    리소스 이름 충돌을 방지하기 위해 키링은 삭제할 수 없습니다. 키링과 키에는 청구 가능 비용이나 할당량 제한이 없으므로 삭제하지 않아도 비용이나 프로덕션 한도에 영향을 미치지 않습니다. 키 및 키 자료 삭제에 대한 자세한 내용은 이 문서 뒷부분의 삭제 섹션을 참조하세요.

  • 키 메타데이터: 리소스 이름, KMS 리소스의 속성(예: IAM 정책), 키 유형, 키 크기, 키 상태, 위의 항목에서 파생된 모든 데이터를 말합니다. 키 메타데이터는 키 자료와 다르게 관리할 수 있습니다.

  • 키 버전: 특정 시점에 하나의 키와 관련된 키 자료를 나타냅니다. 키 버전은 실제 키 자료가 포함된 리소스입니다. 버전 번호는 버전 1부터 순차적으로 번호가 지정됩니다. 키가 순환되면 새 키 자료로 새로운 키 버전이 생성됩니다. 동일한 논리 키는 시간이 지남에 따라 여러 버전을 가질 수 있으므로 각 버전의 사용은 제한적입니다. 대칭 키에는 항상 기본 버전이 있습니다. 이 버전이 기본적으로 암호화에 사용됩니다. Cloud KMS는 대칭 키를 사용하여 복호화를 수행할 때 복호화 수행에 필요한 키 버전을 자동으로 식별합니다.

2.2. 키 계층 구조

다음 다이어그램은 Google 내부 키 관리 서비스의 키 계층 구조를 보여줍니다. Cloud KMS는 Google의 내부 KMS를 활용하여 Google KMS로 Cloud KMS 암호화 키를 래핑합니다. Cloud KMS는 Google KMS와 동일한 신뢰할 수 있는 루트를 사용합니다. 다이어그램 아래에 관련 정의가 소개되어 있습니다.

'내부 키 계층 구조의 다이어그램'

  • 데이터 암호화 키(DEK): 데이터 암호화에 사용되는 키입니다.
  • 키 암호화 키(KEK): 데이터 암호화 키를 암호화하거나 래핑하는 데 사용되는 키입니다. 모든 Cloud KMS 플랫폼 옵션(소프트웨어, 하드웨어, 외부 백엔드)을 사용하여 키 암호화 키를 제어할 수 있습니다.
  • KMS 마스터 키: 키 암호화 키(KEK)를 암호화하는 데 사용되는 키입니다. 이 키는 메모리에 배포됩니다. KMS 마스터 키는 하드웨어 기기에 백업됩니다. 이 키는 키 암호화를 담당합니다.
  • 루트 KMS: Google의 내부 키 관리 서비스입니다.

2.3. 운영

  • 프로젝트: Cloud KMS 리소스는 다른 모든 Google Cloud 리소스와 마찬가지로 Google Cloud 프로젝트에 속합니다. Cloud KMS 키가 있는 프로젝트가 아닌 다른 프로젝트에서 데이터를 호스팅할 수 있습니다. 이 기능은 키 관리자와 데이터 관리자 간의 업무 분리에 관한 권장사항을 지원합니다.
  • 위치: 프로젝트 내에서 Cloud KMS 리소스는 위치에 생성됩니다. 자세한 내용은 지역 및 리전을 참조하세요.

3. Cloud KMS 플랫폼 개요

Cloud KMS 플랫폼은 여러 암호화 알고리즘을 지원하며 하드웨어 및 소프트웨어 지원 키를 모두 사용하여 암호화 및 디지털 방식으로 서명하는 방법을 제공합니다. Cloud KMS 플랫폼은 ID 및 액세스 관리(IAM) 및 Cloud 감사 로그와 통합되어 개별 키에 대한 권한을 관리하고 키가 어떻게 사용되는지 감사할 수 있습니다.

'Cloud KMS 아키텍처 다이어그램'

위 다이어그램은 Cloud KMS 플랫폼의 주요 구성요소를 보여줍니다. 관리자는 Google Cloud Console 또는 gcloud 명령줄 도구를 사용하거나 REST 또는 gRPC API를 구현하는 애플리케이션을 통해 키 관리 서비스에 액세스합니다. 애플리케이션은 REST API 또는 gRPC를 사용하여 키 관리 서비스에 액세스합니다. 애플리케이션은 고객 관리 암호화 키(CMEK)를 사용하도록 설정된 Google 서비스를 사용할 수 있으며 CMEK는 Cloud KMS API를 사용하게 됩니다. Cloud KMS API를 사용하면 소프트웨어(Cloud KMS) 또는 하드웨어(Cloud HSM) 키를 사용할 수 있습니다. 소프트웨어 기반 및 하드웨어 기반 키는 모두 Google의 중복 백업 보호 기능을 활용합니다.

Cloud KMS 플랫폼을 사용하면 키를 만들 때 보호 수준을 선택하여 어떤 키 백엔드가 키를 만들고 향후 해당 키에 모든 암호화 작업을 수행할지 결정할 수 있습니다. Cloud KMS 플랫폼은 Cloud KMS API에 SOFTWAREHSM 보호 수준으로 노출되는 두 개의 백엔드(Cloud EKM 제외)를 제공합니다. SOFTWARE 보호 수준은 암호화 작업을 수행하기 위해 소프트웨어 보안 모듈에서 래핑 해제하는 키에 적용됩니다. HSM 보호 수준은 키로 모든 암호화 작업을 수행하는 하드웨어 보안 모듈에서만 래핑 해제할 수 있는 키에 적용됩니다.

Google Cloud는 Cloud Storage, BigQuery, Compute Engine을 포함한 여러 서비스에 CMEK를 지원합니다. CMEK를 사용하면 이러한 서비스가 데이터를 보호하는 데 사용하는 암호화 키를 Cloud KMS 플랫폼을 통해 관리할 수 있습니다.

Cloud KMS 암호화 작업은 FIPS 140-2 검증 모듈에서 수행합니다. 보호 수준이 SOFTWARE인 키와 이러한 키로 수행된 암호화 작업은 FIPS 140-2 Level 1을 준수합니다. 보호 수준이 HSM인 키와 이러한 키로 수행된 암호화 작업은 FIPS 140-2 Level 3을 준수합니다.

3.1. 환경 및 종속 항목

이 섹션에서는 Cloud KMS 플랫폼이 실행되는 Google 인프라와 인프라가 사용하는 통신 프로토콜에 대해 자세히 설명합니다.

3.1.1. Cloud KMS Borg 작업

Cloud KMS 플랫폼 요소는 프로덕션 Borg 작업으로 실행됩니다. Borg는 API 제공 작업 및 일괄 작업을 처리하기 위한 Google의 대규모 클러스터 관리자입니다. 물리적 인프라 및 프로덕션 인프라의 보안에 대한 자세한 내용은 Google 인프라 보안 설계 개요를 참조하세요.

3.1.1.1. Cloud KMS API 제공 작업

Cloud KMS API 제공 작업은 고객의 키 관리 및 사용 요청을 처리하는 프로덕션 Borg 작업입니다. 이러한 제공 작업은 Cloud KMS를 사용할 수 있는 모든 Google Cloud 리전에서 실행됩니다. 각 작업은 단일 리전과 연결되며, 연결된 Google Cloud 리전 내에 지리적으로 위치한 시스템의 데이터에만 액세스하도록 구성됩니다. 키 상주에 대한 자세한 내용은 이 문서 뒷부분의 리전성을 참조하세요.

3.1.1.2. Cloud KMS 일괄 작업

Cloud KMS 플랫폼은 다양한 일정에서 프로덕션 Borg 작업으로 실행되는 여러 일괄 작업도 유지관리합니다. 일괄 작업은 리전별로 수행되며 연결된 Google Cloud 리전에서만 데이터를 집계하고 작업을 실행합니다. 이러한 작업이 수행하는 태스크는 다음과 같습니다.

  • 고객 결제를 위한 활성 키 계산
  • Cloud KMS의 공개 프로토콜 버퍼 API에서 리소스를 집계하고 메타데이터를 Cloud 애셋 인벤토리로 전달. 여기서 리소스는 Cloud KMS가 관리하는 모든 리소스를 의미합니다(예: 키 및 키링).
  • 비즈니스 분석을 위한 모든 리소스 및 보고 정보 집계
  • 고가용성을 고려한 데이터 스냅샷 생성
  • 기본 Datastore에 저장된 모든 데이터가 손상되지 않았는지 확인
  • KMS 마스터 키가 순환될 때 고객 키 자료를 다시 암호화
3.1.1.3. Cloud KMS 키 스냅샷

고가용성을 유지하기 위해 Cloud KMS 플랫폼은 Cloud KMS API 서버 작업을 호스팅하는 공유 서비스의 각 인스턴스에 중복 Datastore를 유지합니다. 각 서비스는 스냅샷 서비스의 자체 인스턴스를 배포합니다. 이러한 중복성은 한 영역에서 발생한 장애가 다른 영역에 미치는 영향이 최소화되도록 서비스를 독립적으로 분리합니다. Cloud KMS API 작업은 암호화 작업을 수행해야 하는 경우 기본 Datastore와 로컬 스냅샷 작업을 동시에 쿼리합니다. 그런 다음 Cloud KMS API는 요청을 먼저 완료하는 작업을 사용합니다. 스냅샷을 진행하는 파이프라인에서 극도의 비활성 데이터가 제공되는 지연을 방지하기 위해 데이터가 2시간보다 오래된 경우 API 서버는 스냅샷 작업의 결과를 사용하지 않습니다. 스냅샷은 각 리전에서 지속적으로 실행되는 일괄 작업의 출력으로 생성됩니다. 스냅샷은 키 자료와 연결된 클라우드 리전에 있습니다.

3.1.2. 클라이언트-서버 간 통신

Google은 애플리케이션 레이어 전송 보안(ALTS)을 사용하여 Google의 리모트 프로시져 콜(RPC) 메커니즘을 사용하는 클라이언트와 서버 간 통신(전송 중인 데이터 암호화)의 보안을 제공합니다. ALTS는 다음 기능을 제공합니다.

  • 애플리케이션에 대한 P2P 인증 프로토콜
  • 레코드 암호화 프로토콜
  • 승인을 위해 인증된 사용자를 노출하는 API

ALTS의 핸드셰이크 및 레코드 암호화 프로토콜은 전송 계층 보안(TLS) 핸드셰이크레코드 프로토콜과 비슷합니다. ALTS는 다양한 절충을 통해 Google의 프로덕션 환경에 맞게 최적화하며 전체 프로덕션 하드웨어 및 소프트웨어 스택에 완전히 통합됩니다. 자세한 내용은 이 문서 뒷부분의 Cloud KMS 플랫폼 운영 환경을 참조하세요.

4. Cloud KMS 플랫폼 아키텍처 세부정보

이 섹션에서는 키 자료의 보안Datastore 보호를 시작으로 아키텍처 세부정보를 살펴봅니다. 그런 다음 키 자료의 소스 옵션에 대해 자세히 설명합니다.

이 섹션에서는 고객 관리 암호화 키(CMEK) 옵션도 함께 설명합니다.

이 문서에서는 지금까지 소개한 아키텍처 구조가 어떻게 사용되는지에 대한 동적 뷰를 제공하기 위해 키 자료 폐기 관련 내용을 포함하여 Cloud KMS 요청의 수명 주기를 설명합니다.

4.1. 키 자료 보안

Cloud KMS에서 키 자료는 항상 저장 상태 뿐만 아니라 전송 중에도 암호화됩니다 키 자료는 다음과 같은 경우에만 복호화됩니다.

  • 고객이 사용하는 경우
  • 고객 키 자료를 보호하기 위해 사용되는 Google의 내부 키가 순환 중 또는 무결성 점검 중인 경우

Cloud KMS에 대한 고객 요청은 전송 중에 고객과 Google 프런트엔드(GFE) 간 TLS를 사용하여 암호화됩니다. 이 섹션의 앞부분에서 클라이언트-서버 간 통신에 대해 설명하면서 언급한 애플리케이션 레이어 전송 보안(ALTS)은 여러 데이터 센터의 Cloud KMS 작업과 백엔드 간 암호화에 사용됩니다. ALTS 및 전송 중인 데이터 암호화는 이 문서 뒷부분에 있는 Cloud KMS 요청의 수명 주기에 자세히 설명되어 있습니다.

인증은 Google 데이터 센터 내에서 뿐만 아니라 여러 Google 데이터 센터 간에 수행되는 모든 KMS 작업에서 이루어집니다.

Google의 정책은 확인 가능한 방식으로 빌드, 테스트, 검토된 소스 코드만 작업에서 사용하도록 하는 것입니다. Borg용 Binary Authorization(BAB)은 이 정책을 운영 수준에서 시행하며 자세한 내용은 이 보안 문서에서 확인할 수 있습니다.

Cloud KMS API 작업은 IAM 정책 또는 순환 기간과 같은 키 메타데이터에 액세스할 수 있습니다. 버그나 고객 문제와 같은 유효하고 문서화된 비즈니스 근거를 갖춘 Google 직원도 키 메타데이터에 액세스할 수 있습니다. 액세스는 내부적으로 로깅되며 액세스 투명성이 적용되는 데이터와 관련된 로그도 자격을 갖춘 고객에게 제공됩니다.

그러나 Cloud KMS API 작업은 키 자료에 액세스할 수 없으며 API 인터페이스 또는 다른 사용자 인터페이스를 통해서는 키 자료를 내보내거나 볼 수 없습니다. 어떤 Google 직원도 암호화되지 않은 고객 키 자료에 액세스할 수 없습니다. 키 자료는 루트 KMS에서 마스터 키로 추가로 암호화되며 어떤 개인도 이 키 자료에 직접 액세스할 수 없습니다.

4.2. Datastore 보호

이 섹션에서는 Google KMS가 키 데이터를 보호하는 방법을 설명합니다.

4.2.1. 마스터 키

Cloud KMS는 마스터 키를 사용하여 저장 중인 모든 고객 키를 래핑합니다. 각 Cloud KMS 서버는 시작 시 마스터 키의 복사본을 하드 종속 항목으로 가져오며 마스터 키의 새 복사본이 매일 검색됩니다. 마스터 키는 주기적으로 다시 암호화됩니다.

4.2.2. 순환 정책

키 순환은 키 자료 처리에 일반적으로 적용되는 권장사항의 일부입니다. Cloud KMS Datastore 보호에 사용되는 키에 대한 순환 정책이 있습니다. 키 순환 정책은 Cloud KMS 키를 래핑하는 Google 내부 KMS 마스터 키에도 적용됩니다. KMS 마스터 키에는 최대 90일 기한으로 예약되는 암호문이 설정되고 클라이언트 캐시 키에는 최대 1일의 기한이 설정됩니다. Cloud KMS는 24시간마다 KMS 작업의 마스터 키를 새로고침하고 매월 모든 고객 키를 다시 암호화합니다.

4.2.3. 데이터 상주

각 Cloud KMS Datastore의 기반이 되는 데이터는 데이터가 연결된 Google Cloud 리전 내에서만 유지됩니다. 이는 멀티 리전인 위치(예: us 멀티 리전)에도 적용됩니다. 데이터 상주에 대한 자세한 내용은 이 문서 뒷부분의 리전성을 참조하세요.

4.3. 생성 후 키 가용성

Cloud KMS는 Cloud KMS Datastore가 키를 생성하는 트랜잭션을 커밋하고 스토리지 계층이 해당 키의 생성을 인식한 직후에 키 사용을 허용합니다.

4.4. Cloud KMS 소프트웨어 백엔드: 소프트웨어 보호 수준

SOFTWARE 보호 수준은 소프트웨어에서 암호화 작업이 수행되는 키에 적용됩니다. 이 섹션에서는 이 수준이 구현되는 방식에 대해 자세히 설명합니다.

4.4.1. 알고리즘 구현

소프트웨어 키의 경우 Cloud KMS는 Google의 BoringSSL 구현 내에서 BoringCrypto 모듈(BCM)을 사용하여 모든 관련 암호화 작업을 수행합니다. BCM은 FIPS 140-2 검증을 받았습니다. Cloud KMS 바이너리는 이 모듈의 FIPS 140-2 Level 1 검증 암호화 기본 요소에 대해 빌드됩니다. 이 모듈에서 다루는 최신 알고리즘은 Google의 문서 페이지에 나열되어 있으며 여기에는 AES256-GCM 대칭 및 RSA 2048, RSA 3072, RSA 4096, EC P256, EC P384 비대칭 암호화 키를 통한 암호화, 복호화, 서명 작업이 포함됩니다.

4.4.2. 난수 생성 및 엔트로피

암호화 키를 생성할 때 Cloud KMS는 BoringSSL을 사용합니다. FIPS 140-2를 사용하려면 자체 PRNG(DRBG라고도 함)를 사용해야 합니다. BoringCrypto에서 Cloud KMS는 AES-256을 사용하는 CTR-DRBG만 사용합니다. 이는 나머지 시스템이 임의의 데이터를 가져오는 기본 인터페이스인 RAND_bytes에 출력을 제공합니다. 이 PRNG는 Linux 커널의 RNG에서 시드되며, Linux 커널의 RNG는 여러 독립적인 엔트로피 소스로부터 시드됩니다. 이러한 시드에는 디스크 탐색에 대한 미세 측정 및 패킷 간 도착 시간과 같은 데이터 센터 환경의 엔트로피 이벤트와 Intel의 RDRAND 지침(있는 경우)이 포함됩니다. BoringSSL(FIPS 준수 모드)용 난수 생성기의 동작에 대한 자세한 내용은 RNG 설계를 참조하세요.

4.5. Cloud KMS HSM 백엔드: 하드웨어 보호 수준

Cloud HSM 서비스는 Cloud KMS에 하드웨어 지원 키를 제공합니다. 고객에게는 Google 데이터 센터에서 완전 관리형 하드웨어 보안 모듈(HSM)로 보호되는 암호화 키를 관리하고 사용할 수 있는 기능이 제공됩니다. 해당 서비스는 가용성이 높으며 수평으로 자동 확장됩니다. 키는 키링이 정의된 KMS 리전의 암호화 방법을 따릅니다. Cloud HSM을 활용하면 사용자가 생성하고 사용하는 키는, 키가 생성될 때 지정된 리전에 속한 HSM 클러스터의 외부에서 구체화될 수 없습니다. Cloud HSM을 사용하면 암호화 키가 하드웨어 기기 내에서만 생성되고 사용됨을 확실히 증명할 수 있습니다. 기존 Cloud KMS 고객이 Cloud HSM을 사용하기 위해 애플리케이션을 변경할 필요는 없습니다. Cloud KMS 소프트웨어 백엔드와 동일한 API 및 클라이언트 라이브러리를 사용하여 Cloud HSM 서비스에 액세스합니다.

Cloud HSM은 FIPS 140-2 Level 3 검증을 받고 항상 FIPS 모드로 실행되는 HSM을 사용합니다. FIPS 표준은 HSM에서 사용하는 암호화 알고리즘 및 난수 생성을 지정합니다.

4.5.1. Cavium HSM

Cavium HSM PCIe 카드는 공급업체에서 FIPS 140-2 Level 3 준수를 검증받습니다. 현 인증서는 요청 시 받아보실 수 있습니다.

4.5.2. HSM 키 계층 구조

다음 다이어그램의 상단에는 Cloud KMS가 나타나 있습니다. Cloud HSM이 고객 키를 래핑하면 Cloud KMS가 Google의 Datastore로 전달된 HSM 키를 래핑합니다.

'HSM 키 계층 구조 다이어그램'

Cloud HSM에는 Cloud HSM 관리 도메인 내의 자료 마이그레이션을 제어하는 키(표시되지 않음)가 있습니다. 한 리전에 여러 HSM 관리 도메인이 있을 수 있습니다.

HSM 루트 키에는 2가지 특성이 있습니다.

  1. HSM에서 생성되고 전체 기간 동안 HSM의 잘 정의된 경계를 절대 벗어나지 않습니다. 다른 HSM 또는 백업 HSM에서 복제될 수 있습니다.
  2. 키 암호화 키로 사용하여 HSM에서 사용하는 고객 키를 직접 또는 간접적으로 래핑할 수 있습니다.

HSM 루트 키로 래핑된 고객 키를 HSM에서 사용할 수 있지만 HSM은 고객 키의 일반 텍스트를 반환하지 않습니다. HSM은 작업에만 고객 키를 사용합니다.

4.5.3. Datastore 보호

HSM은 키의 영구 스토리지로 사용되지 않으며 키를 사용하는 동안에만 키를 저장합니다. HSM 스토리지에 제약이 있기 때문에 HSM 키는 암호화되어 Cloud KMS 키 Datastore에 저장됩니다. 이 주제는 이 문서 뒷부분의 Datastore 백엔드에 자세히 설명되어 있습니다.

4.5.4. 순환 정책

Cloud HSM의 키 보호 전략에는 여러 유형의 키가 사용됩니다. 고객은 자체 키를 순환하고 Cloud KMS를 사용하여 HSM 키를 순환시킵니다.

4.5.5. 프로비저닝 및 처리 프로세스

HSM의 프로비저닝은 단일 행위자 침해를 방지하기 위한 다자간 승인 제어를 비롯한 여러 물리적 및 논리적 보호 장치를 갖춘 실험실에서 수행됩니다.

다음은 Cloud HSM 시스템 수준 불변 항목입니다.

  1. 고객 키는 일반 텍스트로 추출할 수 없습니다.
  2. 고객 키는 원래 리전의 외부로 이동할 수 없습니다.
  3. 프로비저닝된 HSM의 모든 구성 변경사항은 여러 보안 보호 수단으로 보호됩니다.
  4. Cloud HSM 관리자와 로깅 관리자 간 업무 분리를 준수하며 관리 작업이 로깅됩니다.
  5. HSM은 운영 수명 주기 전반에 걸쳐 악의적인 하드웨어 또는 소프트웨어 수정이나 보안 비밀의 무단 추출 등의 조작에서 보호되도록 설계됩니다.

4.5.6. 공급업체 제어 펌웨어

HSM 펌웨어는 HSM 공급업체에서 디지털로 서명합니다. Google은 HSM 펌웨어를 만들거나 업데이트할 수 없습니다. 테스트에 사용되는 개발 펌웨어를 포함하여 공급업체의 모든 펌웨어가 서명됩니다.

4.5.7. 리전성

고객 키는 특정 HSM 루트 키와의 결합으로 인해 특정한 지리적 리전에 할당됩니다. 예를 들어 us-west1 리전을 지정하여 생성된 키는 us-east1 리전 또는 us 멀티 리전으로 마이그레이션할 수 없습니다. 마찬가지로 us 멀티 리전에서 생성된 키는 us-west1 리전의 내부 또는 외부로 마이그레이션할 수 없습니다.

4.6. Cloud KMS: 키 가져오기

자체 키를 클라우드 환경으로 가져오기를 원하는 경우도 있습니다. 예를 들어 클라우드 데이터를 암호화하는 데 사용되는 키가 특정 방식이나 환경에서 생성되어야 하는 규제 요건이 존재할 수 있습니다. Cloud KMS를 사용하면 온프레미스에서 만들거나 외부 키 관리자로 만든 자체 암호화 키를 가져올 수 있습니다. 키 가져오기를 사용하면 이러한 키를 가져오고 해당 규제 의무도 준수할 수 있습니다. 또한 비대칭 키를 가져와 서명 기능을 클라우드로 확장할 수 있습니다.

키 가져오기의 일환으로 Cloud KMS는 지원되는 가져오기 방법 중 하나를 사용하여 공개 키/비공개 키 쌍인 래핑 키를 생성합니다. 이 래핑 키로 키 자료를 암호화하면 전송 중인 키 자료가 보호됩니다.

이 Cloud KMS 공개 래핑 키는 클라이언트에서 가져올 키를 암호화하는 데 사용됩니다. 이 공개 키와 일치하는 비공개 키는 Google Cloud 내에 저장되며 키가 Google Cloud 프로젝트에 도달한 후에 키를 래핑 해제하는 데 사용됩니다. 선택한 가져오기 메서드에 따라 래핑 키를 만드는 데 사용되는 알고리즘이 결정됩니다. 키 자료가 래핑된 후에는 Cloud KMS에서 새 키 또는 키 버전으로 가져올 수 있습니다.

가져온 키는 HSM 또는 SOFTWARE 보호 수준에도 사용할 수 있습니다.

Cloud HSM의 경우 Cloud HSM 내에서만 래핑 키의 비공개 키 부분을 사용할 수 있습니다. 비공개 키 부분을 Cloud HSM으로 제한하면 Google이 Cloud HSM 외부에서 키 자료 래핑을 해제하지 못하게 됩니다.

4.7. 고객 관리 암호화 키(CMEK)

기본적으로 Google Cloud는 비활성 상태로 저장된 모든 고객 데이터를 암호화하며 암호화에 사용되는 키는 Google에서 관리합니다. 일부 Google Cloud 제품의 경우 고객이 Cloud KMS를 사용하여 암호화에 사용되는 키를 관리할 수 있습니다. CMEK는 소프트웨어 및 하드웨어 지원 키 모두에 사용할 수 있습니다. 고객은 Cloud KMS를 사용하여 키 생성, 사용 설정, 사용 중지, 순환, 폐기와 같은 키의 여러 측면을 제어하고 적절한 IAM 권한을 관리할 수 있습니다. Cloud KMS에는 특정 권한과 제한이 있으며 특정 사용자 및 서비스 계정에 부여되어 권장되는 권한 분리를 시행할 수 있는 여러 사전 정의된 IAM 역할이 포함됩니다.

다음 주제는 CMEK를 지원하는 Cloud KMS 플랫폼과 통합된 제품에 대한 세부정보를 제공합니다.

사용되는 키 버전에 키 순환이 미치는 영향은 제품이 CMEK를 구현하는 방법에 따라 달라집니다. 일반적으로 Cloud KMS 키를 순환해도 연결된 CMEK 서비스의 데이터는 다시 암호화되지 않습니다. 예를 들어 BigQuery는 테이블과 연결된 Cloud KMS 키가 순환될 때 테이블 암호화 키를 자동 순환하지 않습니다. 기존 BigQuery 테이블은 생성될 때 사용한 키 버전을 계속 사용합니다. 새 BigQuery 테이블은 현재 키 버전을 사용합니다. 자세한 내용은 각 제품의 문서를 참조하세요.

CMEK 통합 및 CMEK 준수 서비스의 전체 목록은 이 문서를 참조하세요. Google은 다른 Google Cloud 제품의 CMEK 통합에 계속 투자하고 있습니다.

4.8. Cloud KMS 요청의 수명 주기

이 섹션에서는 지금까지 소개한 아키텍처 구조가 어떻게 사용되는지에 대한 동적 뷰를 제공하기 위해 키 자료 폐기 관련 내용을 포함하여 Cloud KMS 요청의 수명 주기를 설명합니다.

'KMS 요청 수명 주기 다이어그램'

이 수명 주기의 단계는 다음과 같습니다.

  1. 고객 또는 고객을 대신하여 실행되는 작업에서 Cloud KMS 서비스(https://cloudkms.googleapis.com)에 대한 요청을 작성합니다. DNS는 이 주소를 Google 프런트엔드(GFE)의 Anycast IP 주소로 확인합니다.
  2. GFE는 공개 DNS 이름, 서비스 거부(DoS) 보호, TLS 종료의 공개 IP 호스팅을 제공합니다. 고객이 요청을 전송하면 일반적으로 고객의 요청이 타겟팅된 위치에 관계없이 고객과 가까운 GFE로 라우팅됩니다. GFE는 TLS 협상을 처리하고 요청 URL과 매개변수를 사용하여 어느 Global Software Load Balancer(GSLB)가 요청을 라우팅할지 결정합니다.
  3. Cloud KMS 리전마다 별도의 GSLB 타겟이 있습니다. 요청이 Google의 us-east1에 도착하고 us-west1을 대상으로 하는 경우 us-east1us-west1 데이터 센터 사이로 요청이 라우팅됩니다. 데이터 센터 간의 모든 통신은 GFE와 Cloud KMS 작업을 상호 인증하는 ALTS를 사용하여 전송 시 암호화됩니다.
  4. 요청이 Cloud KMS 작업에 도달하면 먼저 모든 Google Cloud 서비스에 공통된 작업의 상당 부분을 맡고 있는 프레임워크에서 처리합니다. 이 프레임워크는 사용자를 인증하고 여러 검사를 수행하여 다음을 확인합니다.
    • 고객에게 유효한 사용자 인증 정보가 있으며 인증할 수 있습니다.
    • Google Cloud 프로젝트에 Cloud KMS API가 사용 설정되어 있고 유효한 결제 계정이 있습니다.
    • 할당량이 요청을 실행하기에 충분합니다.
    • 고객이 허용 목록에 있어 관련 Google Cloud 리전을 사용할 수 있습니다.
    • VPC 서비스 제어가 요청을 거부하지 않습니다.
  5. 이러한 검사를 통과하면 프레임워크는 Cloud KMS에 요청 및 사용자 인증 정보를 전달합니다. Cloud KMS는 요청을 파싱하여 액세스 중인 리소스를 파악한 다음 IAM을 확인하여 호출자가 요청을 수행할 권한이 있는지 알아봅니다. 또한 IAM은 Cloud KMS에 요청 발생을 감사 로그에 기록해야 하는지 여부를 알려줍니다.
  6. 요청이 인증 및 승인되면 Cloud KMS는 리전 내 Datastore 백엔드를 호출하여 요청된 리소스를 가져옵니다. 리소스를 가져오면 고객 키 자료가 사용을 위해 복호화됩니다.
  7. Cloud KMS는 키 자료로 암호화 작업을 수행하여 키의 보호 수준에 따라 키의 래핑된 버전을 Cloud KMS 소프트웨어 백엔드 또는 Cloud HSM으로 전달합니다.
  8. 암호화 작업이 완료된 후에는 응답이 요청과 동일한 유형의 GFE-to-KMS 채널을 통해 고객에게 다시 전송됩니다.
  9. 응답이 반환되면 Cloud KMS도 일부 이벤트를 비동기적으로 트리거합니다.
    • 감사 및 요청 로그가 채워지고 작성 대기 중입니다.
    • 보고서가 청구 및 할당량 관리를 위해 전송됩니다.
    • 요청이 리소스의 메타데이터를 업데이트한 경우 변경사항이 일괄 작업 업데이트를 통해 Cloud 애셋 인벤토리로 전송됩니다.

4.9. 키 자료의 폐기

Google Cloud에서 데이터 삭제는 이 백서에 설명되어 있습니다. 키 자료는 고객 데이터로 간주되므로 백서에서 설명하는 접근 방식이 Cloud KMS에 적용됩니다. 또한 Google은 Cloud KMS 외부에서 키 자료를 절대 공유하지 않으므로 24시간의 삭제 대기 시간이 끝나고 백업이 만료되면 요청에 따라 키 자료가 폐기됩니다. Cloud KMS 제어 외부에 있는 가져온 키 사본에 대해서는 이 프로세스가 보장되지 않습니다.

위 설명대로 키 자료는 폐기되지만 키 및 키링은 삭제할 수 없습니다. 키 버전도 삭제할 수 없지만 리소스가 더 이상 사용되지 않도록 키 버전 자료를 폐기할 수 있습니다. 키링과 키에는 청구 가능 비용이나 할당량 제한이 없으므로 삭제하지 않아도 비용이나 프로덕션 한도에 영향을 미치지 않습니다.

폐기가 예약된 후에는 암호화 작업에 키 버전을 사용할 수 없습니다. 24시간 내에 사용자는 키 버전이 폐기되지 않도록 복원할 수 있습니다.

5. Cloud KMS 플랫폼 운영 환경

Cloud KMS 플랫폼의 운영 환경에는 키 자료를 보호하면서 안정성, 내구성, 가용성을 최적화하도록 설계된 데이터 스토리지 및 보안 정책, 액세스 제한, 위험 완화 전략이 포함되어 있습니다. 이 섹션에서는 서비스의 운영 구조, 운영팀 구성원의 책임, 인증 메커니즘, 감사 및 로깅 프로토콜에 대해 설명합니다. 다음 설명은 소프트웨어 및 하드웨어 지원 키 기능 모두에 적용됩니다.

5.1. 소프트웨어 엔지니어, 사이트 안정성 엔지니어, 시스템 운영자

소프트웨어 엔지니어는 제품 관리자와 사이트 안정성 엔지니어(SRE) 등의 다른 이해관계자와 협력하여 시스템을 설계하고 궁극적으로 Cloud KMS 서비스를 위한 많은 코드와 테스트를 작성하는 업무를 담당합니다. 코드에는 고객 요청을 처리하는 기본 작업과 데이터 복제 및 청구와 같은 활동을 위한 보조 작업이 포함됩니다. 또한 SRE가 코드를 작성할 수도 있습니다. 그러나 소프트웨어 엔지니어와 SRE의 업무는 분리되어 있습니다. SRE는 주로 Cloud KMS 작업을 위해 프로덕션 환경을 유지관리하는 일을 합니다. SRE는 엔지니어링 및 운영 작업을 통해 안정성을 측정하고 달성합니다.

시스템 운영자는 Cloud KMS의 빌드 및 출시 프로세스, 모니터링, 알림, 용량 계획을 담당합니다. 이들은 고객 문제 및 Cloud KMS 중단에 대한 최초 대응자입니다. 예를 들어 시스템 운영자는 도구와 자동화를 활용하여 수동 시스템의 작업을 최소화함으로써 장기적인 가치를 향상하는 일에 주력할 수 있습니다.

5.2. Cloud KMS 리소스의 리전성

다음 4가지 유형의 Google Cloud 위치 중 한 곳에 Cloud KMS 리소스를 만들 수 있습니다.

  • 리전 위치: 리전 위치는 아이오와와 같은 특정 지리적 장소에 대한 영역으로 구성됩니다.
  • 이중 리전 위치: 이중 리전 위치는 아이오와 및 사우스캐롤라이나와 같이 두 곳의 특정 지리적 장소에 대한 영역으로 구성됩니다.
  • 멀티 리전 위치: 멀티 리전 위치는 미국과 같은 광범위한 지리적 영역에 분포된 여러 영역으로 구성됩니다.
  • 전역 위치: 전역 위치는 전 세계에 분산된 영역으로 구성됩니다. 전역 위치에 Cloud KMS 리소스를 만들면 전 세계 영역에서 사용할 수 있습니다.

위치는 특정 리소스와 관련된 Cloud KMS에 대한 요청이 처리되는 지리적 리전과 해당 암호화 키가 저장되는 위치를 나타냅니다.

사용 가능한 Cloud KMS 위치에 대한 자세한 내용은 Cloud KMS 문서를 참조하세요.

5.2.1. 클라우드 리전 및 데이터 센터

Google Cloud 리전에는 특정 데이터 센터 또는 단일 리전, 이중 리전, 멀티 리전 또는 전역 위치 지정에 따른 지정된 데이터 센터 집합이 포함됩니다. Google Cloud 리전에 대한 자세한 내용은 Google Cloud 위치를 참조하세요.

각 데이터 센터에는 컴퓨팅, 네트워킹 또는 데이터 스토리지를 위한 머신이 있습니다. 이러한 머신은 Google의 Borg 인프라를 실행합니다.

Google 데이터 센터에는 엄격한 물리적 보안 요건이 있습니다. 사용자 데이터를 포함할 수 있는 모든 물리적 공간에는 출입자를 인증하는 데 사용되는 배지 리더 또는 홍채 스캐너가 있는 진입로가 필요합니다. 여러 사람을 한꺼번에 입장시키기 위해 문을 열어둔 채로 놔두어서는 안되며 각 사용자가 개별적으로 인증해야 합니다. 보안 요원이 검사한 후 명시적으로 승인되지 않은 가방은 이러한 영역에서 반출입이 허용되지 않습니다. 데이터를 전송하거나 기록할 수 있는 전자기기를 가져오거나 내보내려면 특별한 허가가 필요합니다.

5.2.2. 리전성

일부 업계에서는 암호화 키가 특정 위치에 있어야 합니다. 위의 Cloud KMS 리소스의 리전성에서 소개한 대로 Cloud KMS는 이러한 요건을 충족하는 데 도움이 되는 4가지 유형의 리전 위치를 제공합니다.

단일, 이중 또는 멀티 리전 위치의 경우 Cloud KMS는 해당 위치에서만 고객 소프트웨어 및 하드웨어 지원 키와 키 자료를 만들고, 저장하고, 처리합니다. Cloud KMS에서 사용하는 스토리지 및 데이터 처리 시스템은 키 자료와 연결된 Google Cloud 리전 내의 리소스만 사용하도록 구성됩니다. 이중 또는 멀티 리전 위치에서 생성된 키 자료는 선택한 위치의 경계를 벗어나지 않습니다.

전역 리전의 경우 리전성 보장이 지정되지 않습니다.

Cloud KMS는 키 메타데이터, 사용량 로그 또는 전송 중인 키 자료의 상주를 보장하지 않습니다. 키 메타데이터에는 리소스 이름, 그리고 키 유형, 키 크기, 키 상태와 같은 Cloud KMS 리소스의 속성, IAM 정책, 메타데이터에서 파생된 모든 데이터가 여기에 해당합니다.

CMEK를 사용하는 경우 CMEK와 함께 사용하려는 다른 Google Cloud 제품에서 선택한 커스텀, 이중 또는 멀티 리전 위치에 관계없이 다음과 같은 Cloud KMS 지리적 제한이 키에 적용됩니다.

  • 특정 리전의 경우: 고객 관리 KMS 키의 리전은 특정 Google Cloud 서비스에서 키가 보호하는 리소스의 리전과 항상 상관 관계가 있어야 하므로 단일 리전 키 및 리소스에 대한 상주 제한이 호환되고 시행됩니다.
  • 이중 또는 멀티 리전 위치의 경우: 사용자는 키 및 Google Cloud 리소스에 대해 Google에서 정의하고 상관관계가 있는 멀티 리전을 선택하여 상주 규정 준수를 보장할 수 있습니다. 이 지리적 상주를 보장하려면 다른 제품의 리전이 선택한 Cloud KMS 리전 위치와 일치해야 합니다.

다음 표는 Cloud KMS 키 자료의 상주를 요약하여 보여줍니다.

Cloud KMS 데이터 상주 저장, 사용
(단일 리전)
저장, 사용
(이중/멀티 리전)
소프트웨어 키 자료 상주 이중/멀티 리전을 구성하는 리전에 상주합니다.
하드웨어 키 자료(HSM) 상주 이중/멀티 리전을 구성하는 리전에 상주합니다.

5.2.3. 리전성 모니터링

Google의 내부 데이터 모니터링 서비스는 키 상주를 적극적으로 모니터링합니다. Cloud KMS는 실수로 잘못된 구성을 감지하거나, 키 자료가 구성된 리전의 경계를 벗어나거나, 잘못된 리전에 저장되거나, 잘못된 리전에서 액세스하는 경우 SRE팀 구성원에게 알림을 보냅니다.

5.3. 인증 및 승인

Cloud KMS는 OAuth2, JWT, ALTS와 같은 다양한 인증 메커니즘을 허용합니다. 메커니즘과 관계없이 Cloud KMS는 제공된 사용자 인증 정보를 확인하여 주 구성원(인증되어 있으며 요청을 승인하는 개체)을 식별하고, IAM을 호출하여 주 구성원에게 요청 권한이 있는지 여부와 감사 로그가 작성되어 있는지 여부를 확인합니다.

Cloud KMS는 서비스 관리의 여러 측면에서 공개 Service Control API의 내부 버전을 사용합니다. Cloud KMS 작업이 요청을 처리하기 전에 먼저 Service Control API에 확인 요청을 보내면 다음과 같은 모든 Google Cloud 서비스에 공통된 여러 제어가 적용됩니다.

  • 고객이 Cloud KMS API를 활성화했으며 활성 결제 계정이 있는지 확인합니다.
  • 고객이 할당량을 초과하지 않았는지 확인하고 할당량 사용량을 보고합니다.
  • VPC 서비스 제어를 시행합니다.
  • 고객이 해당 비공개 클라우드 리전의 허용 목록에 있는지 확인합니다.

5.4. 로깅

Cloud KMS는 3가지 유형의 로그(Cloud 감사 로그, 액세스 투명성 로그, 내부 요청 로그)와 연결됩니다.

5.4.1. Cloud 감사 로그

Cloud KMS는 Cloud 감사 로그 로그에 고객 활동을 기록합니다. 고객은 Cloud Console에서 이러한 로그를 볼 수 있습니다. 키 생성 또는 폐기와 같은 모든 관리자 활동이 이 로그에 기록됩니다. 또한 고객은 키를 사용하여 데이터를 암호화하거나 복호화하는 등 키를 사용하는 다른 모든 작업에 로깅을 사용 설정할 수 있습니다. 고객은 로그 보관 기간과 로그를 확인할 수 있는 사용자를 제어합니다.

5.4.2. 액세스 투명성 로그

자격요건을 충족하는 고객은 필요에 따라 액세스 투명성 로그를 사용하도록 설정할 수 있습니다. 이 로그를 통해 Google 직원이 사용자의 Google Cloud 조직에서 수행하는 작업 로그를 확인할 수 있습니다. Cloud 감사 로그의 로그와 더불어 액세스 투명성 로그는 누가, 언제, 어디서, 무엇을 했는지에 대한 질문에 답하는 데 도움이 됩니다.

액세스 투명성 로그를 기존 보안 정보 및 이벤트 관리(SIEM) 도구와 통합하여 이러한 작업의 감사를 자동화할 수 있습니다. 이러한 로그는 Cloud 감사 로그의 로그와 함께 Cloud Console에서 확인할 수 있습니다.

액세스 투명성 로그 항목에는 다음과 같은 유형의 세부정보가 포함됩니다.

  • 영향을 받는 리소스와 작업
  • 작업 수행 시간
  • 작업을 수행한 이유. 이유의 예시로는 고객이 시작한 지원(케이스 번호 포함), Google에서 시작한 지원, 타사 데이터 요청, Google에서 시작한 검토 요청이 있습니다.
  • 데이터를 작업한 직원에 대한 데이터(예: Google 직원의 위치)

5.4.3. 내부 요청 로그

요청 로그는 Cloud KMS 플랫폼으로 전송된 모든 요청의 레코드를 저장합니다. 이 레코드에는 요청 유형(예: API 메서드 또는 프로토콜)과 액세스되는 리소스(예: 리소스 이름, 키 알고리즘 또는 키 보호 수준)에 대한 세부정보가 포함됩니다. 이러한 로그는 고객 일반 텍스트, 암호문 또는 키 자료를 저장하지 않습니다. 새로운 유형의 데이터가 이러한 로그에 추가되기 전에 개인정보 보호 검토를 전문으로 하는 팀이 로깅되는 데이터의 변경사항을 승인해야 합니다.

구성된 TTL(수명)이 만료되면 로그 항목이 영구적으로 삭제됩니다.

Cloud KMS SRE 및 교대로 대기 근무 중인 엔지니어는 요청 로그에 액세스할 수 있습니다. 로그에 대한 수동 액세스와 고객 데이터를 반환하는 액세스에는 유효하고 문서화된 비즈니스 근거가 필요합니다. 몇 가지 구체적인 예외가 있으나, 수동 액세스는 액세스 투명성 로그에 로깅되며 자격이 있는 고객이 액세스할 수 있습니다.

5.5. Datastore 백엔드

Cloud KMS의 Datastore는 가용성과 내구성이 우수하며 보호됩니다.

가용성: Cloud KMS는 가용성이 높고 Google의 중요한 시스템을 지원하는 Google의 내부 Datastore를 사용합니다.

내구성: Cloud KMS는 인증된 암호화를 사용하여 고객 키 자료를 Datastore에 저장합니다. 또한 저장 중에 변경되거나 손상되지 않았음을 확인하는 해시 기반 메시지 인증 코드(HMAC)를 사용하여 모든 메타데이터를 인증합니다. 매시간 일괄 작업은 모든 키 자료 및 메타데이터를 검사하여 HMAC가 유효하며 키 자료를 성공적으로 복호화할 수 있는지 확인합니다. 데이터가 손상된 경우 즉시 조치를 취할 수 있도록 Cloud KMS 엔지니어에게 알림이 전송됩니다.

Cloud KMS는 Datastore에 여러 유형의 백업을 사용합니다.

  • 기본적으로 Datastore는 몇 시간 동안 모든 행의 변경 내역을 보관합니다. 긴급 상황에서는 이 기간을 연장하여 문제를 해결하는 데 더 많은 시간을 할애할 수 있습니다.
  • Datastore는 매시간 스냅샷을 기록합니다. 필요한 경우 스냅샷을 검증하고 복원에 사용할 수 있습니다. 이 스냅샷은 4일 동안 보관됩니다.
  • 매일 전체 백업이 디스크 및 테이프에 복사됩니다.

Cloud KMS팀은 긴급 상황에서 백업을 복원하는 절차를 문서화했습니다.

상주: Cloud KMS Datastore 백업은 연결된 Google Cloud 리전에 상주됩니다. 이러한 백업은 모두 저장 상태에서 암호화됩니다. 백업된 데이터에 대한 액세스는 액세스 근거(예: Google 지원팀에 제출한 티켓 번호)에 따라 통제되며 수동 액세스는 액세스 투명성 로그에 로깅됩니다.

보호: Cloud KMS 애플리케이션 레이어에서 고객 키 자료는 저장되기 전에 암호화됩니다. Datastore 엔지니어는 일반 텍스트 고객 키 자료에 액세스할 수 없습니다. 또한 Datastore는 영구 스토리지에 쓰기 전에 관리하는 모든 데이터를 암호화합니다. 따라서 Google 내부 KMS에 보관된 Datastore 암호화 키에 대한 액세스 권한이 없으면 디스크 또는 테이프를 포함한 기본 스토리지 레이어에 대한 액세스 권한으로는 암호화된 Cloud KMS 데이터에 액세스할 수 없습니다.

6. 추가 자료

자세한 내용은 다음 리소스를 참조하세요.

백서:

기타 문서: