Cloud Key Management Service 심층 탐구

이 콘텐츠는 2023년 7월에 마지막으로 업데이트되었으며 작성된 당시의 상황을 나타냅니다. Google이 지속적으로 고객 보호를 개선함에 따라 Google의 보안 정책 및 시스템은 향후 변경될 수 있습니다.

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

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

다음 표에서는 여러 유형의 Google Cloud 키를 설명합니다.

키 유형	키 관리	키 공유	자동 순환	가격 책정
기본 암호화 키	이러한 키는 Google에서 관리합니다.	여러 고객의 데이터에서 동일한 키 암호화 키(KEK)를 사용할 수 있습니다.	예. 기본 저장 데이터 암호화를 참조하세요.	무료
Cloud KMS 키	이러한 키는 고객이 제어합니다.	고객별로 고유해야 합니다.	대칭 암호화의 경우 자동 순환되며 비대칭 키의 경우 안 됩니다. 키 순환을 참조하세요.	Cloud Key Management Service 가격 책정을 참조하세요.

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

Cloud KMS 설계 원칙

Cloud KMS와 관련하여 Google에서는 가장 광범위한 제어 옵션을 가진 확장 가능하고, 안정적이며, 우수한 솔루션을 제공하는 데 주력합니다. Cloud KMS의 5가지 설계 원칙은 다음과 같습니다.

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

키 자료의 소스 및 관리 옵션

Cloud KMS 플랫폼을 사용하면 직접 사용하거나 다른 클라우드 리소스 및 애플리케이션에서 사용할 수 있도록 중앙 클라우드 서비스에서 암호화 키를 관리할 수 있습니다.

다음 다이어그램은 Google 관리 키 자료에서 고객 제어 키 자료로 정렬된 키에 대한 Google Cloud 포트폴리오를 보여줍니다.

이전 다이어그램에 표시된 옵션은 다음과 같습니다.

• 기본 암호화: Google에서 저장하는 모든 데이터는 고급 암호화 표준(AES) 알고리즘인 AES-256을 사용하여 스토리지 레이어에서 암호화됩니다. 기본 암호화를 위한 키를 생성하고 관리하며, 고객은 키 또는 키 순환 및 관리 제어에 액세스할 수 없습니다. 기본 암호화 키가 고객 간에 공유될 수 있습니다. 자세한 내용은 기본 저장 데이터 암호화를 참조하세요.

• 소프트웨어 생성 키와 Cloud KMS: Cloud KMS를 사용하여 Google에서 생성한 키를 제어할 수 있습니다. Cloud KMS 소프트웨어 백엔드에서는 개발자가 직접 제어하는 대칭 또는 비대칭 키로 데이터를 유연하게 암호화하거나 서명할 수 있습니다.

• 하드웨어 생성 키(Cloud HSM)와 Cloud KMS: Cloud HSM 백엔드와 함께 Cloud KMS를 사용하면 Google이 소유하고 운영하는 HSM(하드웨어 보안 모듈)에서 생성 및 저장되는 키를 소유할 수 있습니다. 하드웨어 보호 키가 필요한 경우 Cloud HSM 백엔드를 사용하여 대칭 키 및 비대칭 키를 FIPS 140-2 Level 3 검증 HSM에서만 사용하도록 할 수 있습니다.

• 키 가져오기가 포함된 Cloud KMS: BYOK 요구사항을 충족하기 위해 직접 생성한 자체 암호화 키를 가져올 수 있습니다. Google Cloud 외부에서 이러한 키를 사용 및 관리하고 Cloud KMS의 키 자료를 사용하여 Google Cloud에 저장한 데이터를 암호화하거나 서명할 수 있습니다.

• 외부 키 관리자가 포함된 Cloud KMS(Cloud EKM): HYOK 요구사항을 충족시키기 위해 Google Cloud 외부에 있는 키 관리자에 저장된 키를 만들고 제어할 수 있습니다. 그런 다음 외부 키를 사용하여 저장 데이터를 보호하도록 Cloud KMS 플랫폼을 설정합니다. 이러한 암호화 키를 Cloud EKM 키와 함께 사용할 수 있습니다. 외부 키 관리 및 Cloud EKM에 대한 자세한 내용은 Cloud EKM 서비스의 안정적인 배포를 위한 참조 아키텍처를 참조하세요.

Cloud KMS에서 생성된 키를 다른 Google Cloud 서비스와 함께 사용하도록 선택할 수 있습니다. 이러한 키를 고객 관리 암호화 키(CMEK)라고 합니다. CMEK 기능을 사용하면 다른 Google Cloud 서비스의 데이터를 보호하는 데 도움이 되는 암호화 키를 생성, 사용, 순환, 폐기할 수 있습니다.

Google의 암호화 개념 및 키 관리

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

키링, 키, 키 버전

다음 다이어그램은 키 그룹을 보여주며 키링과 기본 버전이 하나이고 이전 버전이 여러 개 있는 키를 보여줍니다.

앞의 다이어그램에 표시된 주요 개념은 다음과 같습니다.

• 키: 특정 용도로 사용하는 암호화 키를 나타내는 이름이 지정된 객체입니다. 암호화 작업에 사용되는 실제 비트인 키 자료는 시간이 경과함에 따라 새로운 키 버전을 만들 때 변경될 수 있습니다. 리소스 계층 구조의 키 수준에서 IAM 허용 정책을 할당할 수 있습니다.

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

  Cloud KMS는 비대칭 키와 대칭 키를 모두 지원합니다. 대칭 키는 MAC 서명을 만들거나 검증하거나 대칭 암호화를 위해 일부 데이터 코퍼스를 보호하는 데 사용됩니다. 예를 들어 GCM 모드에서 AES-256을 사용하여 일반 텍스트 블록을 암호화할 수 있습니다. 비대칭 키는 비대칭 암호화 또는 비대칭 서명에 사용할 수 있습니다. 자세한 내용은 지원되는 목적 및 알고리즘을 참조하세요.

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

  리소스 이름 충돌 방지를 위해 키링 또는 키를 삭제할 수 없습니다. 키링과 키에는 청구 가능 비용이나 할당량 제한이 없으므로 삭제하지 않아도 비용이나 프로덕션 한도에 영향을 미치지 않습니다.

• 키 메타데이터: 리소스 이름, KMS 리소스의 속성(예: 허용 정책), 키 유형, 키 크기, 키 상태, 키 및 키링에서 파생된 모든 데이터를 말합니다.

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

소프트웨어 키 계층 구조

다음 다이어그램은 Cloud KMS와 Google의 내부 키 저장소의 키 계층 구조를 보여줍니다. Cloud KMS는 Google의 내부 키 관리 서비스인 키 저장소를 사용하여 Cloud KMS로 암호화된 키를 래핑합니다. 키 래핑은 안전하게 저장하거나 신뢰할 수 없는 채널을 통해 전송하기 위해 키 한 개를 다른 키로 암호화하는 프로세스입니다. Cloud KMS는 키 저장소와 동일한 신뢰할 수 있는 루트를 사용합니다.

이전 다이어그램에 표시된 키 계층 구조는 다음과 같습니다.

1. 데이터 암호화 키(DEK)는 데이터 청크를 암호화합니다.
2. 키 암호화 키(KEK)는 DEK를 암호화하거나 래핑하는 데 사용됩니다. 모든 Cloud KMS 플랫폼 옵션(소프트웨어, 하드웨어, 외부 백엔드)을 사용하여 KEK를 제어할 수 있습니다. KEK가 Cloud KMS에 저장됩니다.
3. KMS 마스터 키는 KEK를 암호화합니다. KMS 마스터 키는 키 저장소에 저장됩니다. 키 저장소에는 Cloud KMS 위치마다 별도의 KMS 마스터 키가 있습니다. Cloud KMS의 KEK는 해당 위치의 KMS 마스터 키로 보호됩니다. 각 Cloud KMS 서버는 시작 시 KMS 마스터 키의 복사본을 하드 종속 항목으로 가져오며 KMS 마스터 키의 새 복사본이 매일 검색됩니다. KMS 마스터 키는 주기적으로 다시 암호화됩니다.
4. KMS 마스터 키는 키 저장소의 키 저장소 마스터 키로 보호됩니다.
5. 키 저장소 마스터 키는 루트 키 저장소 마스터 키로 보호됩니다.

키 저장소에 대한 자세한 내용은 저장 데이터 암호화 자료의 키 관리를 참조하세요.

주요 운영 제약조건

Cloud KMS는 다음 제약조건 내에서 작동합니다.

• 프로젝트: Cloud KMS 리소스는 다른 모든 Google Cloud 리소스와 마찬가지로 Google Cloud 프로젝트에 속합니다. Cloud KMS 키가 있는 프로젝트가 아닌 다른 프로젝트에서 데이터를 호스팅할 수 있습니다. 키 관리자와 데이터 관리자 간의 업무 분리 권장사항을 지원하려면 키 프로젝트에서 소유자 역할을 삭제하면 됩니다.
• 위치: 프로젝트 내에서 Cloud KMS 리소스는 위치에 생성됩니다. 위치에 대한 자세한 내용은 위치 및 리전을 참조하세요.
• 일관성: Cloud KMS는 strong consistency 또는 eventual consistency를 사용하여 키, 키링, 키 버전에 대한 작업을 전파합니다. 자세한 내용은 Cloud KMS 리소스 일관성을 참조하세요.

Cloud KMS 플랫폼 개요

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

위 다이어그램은 Cloud KMS 플랫폼의 주요 구성요소를 보여줍니다.

• 관리자는 Cloud 콘솔 또는 Google Cloud CLI를 사용하여 키 관리 서비스에 액세스합니다.

• 애플리케이션은 REST API, gRPC 또는 클라이언트 라이브러리를 구현하여 키 관리 서비스에 액세스합니다. 애플리케이션에서 CMEK를 사용하도록 설정된 Google 서비스를 사용할 수 있습니다. CMEK는 Cloud Key Management Service API를 차례로 사용합니다. 애플리케이션이 PKCS #11을 사용하는 경우 PKCS #11용 라이브러리를 사용하여 Cloud KMS와 통합할 수 있습니다.

• Cloud KMS API를 사용하면 소프트웨어, 하드웨어 또는 외부 키를 사용할 수 있습니다. 소프트웨어 기반 키와 하드웨어 기반 키 모두 Google의 중복 백업 보호 기능을 사용합니다.

• 하드웨어 키를 사용하는 경우 Google Cloud의 FIPS 140-2 Level 3 인증 HSM에서 키를 저장합니다. 인증에 대한 자세한 내용은 인증서 #4399를 참조하세요.

• Cloud KMS는 Google의 내부 Datastore를 사용하여 암호화된 고객 키 자료를 저장합니다. 이 Datastore는 가용성이 높으며 Google의 많은 중요 시스템을 지원합니다. Datastore 보호를 참조하세요.

• 독립적 백업 시스템은 일정한 간격으로 전체 Datastore를 온라인 및 아카이브 스토리지에 백업합니다. 이 백업은 Cloud KMS가 내구성 목표를 달성할 수 있게 해줍니다. Datastore 보호를 참조하세요.

FIPS 140-2 유효성 검사

Cloud KMS 암호화 작업은 FIPS 140-2 검증 모듈에서 수행합니다. 보호 수준이 SOFTWARE인 키와 이러한 키로 수행된 암호화 작업은 FIPS 140-2 Level 1을 준수합니다. 이러한 암호화 작업에는 Google이 관리하는 오픈소스 암호화 라이브러리인 BoringCrypto가 사용됩니다. 보호 수준이 HSM인 키와 이러한 키로 수행된 암호화 작업은 FIPS 140-2 Level 3을 준수합니다.

Google 인프라 종속 항목

Cloud KMS 플랫폼 요소는 프로덕션 Borg 작업으로 실행됩니다. Borg는 API 제공 작업 및 일괄 작업을 처리하기 위한 Google의 대규모 클러스터 관리자입니다.

물리적 인프라 및 프로덕션 인프라의 보안에 대한 자세한 내용은 Google 인프라 보안 설계 개요를 참조하세요.

Cloud KMS API 제공 작업

Cloud KMS API 제공 작업은 고객의 키 관리 및 사용 요청을 처리하는 프로덕션 Borg 작업입니다. Cloud KMS API 제공 작업은 또한 일정에 따른 키 순환, 비대칭 키 만들기, 키 가져오기와 같은 고객 요청의 지연된 작업을 처리합니다. 이러한 제공 작업은 Cloud KMS를 사용할 수 있는 모든 Google Cloud 리전에서 실행됩니다. 각 작업은 단일 리전과 연결되며, 연결된 Google Cloud 리전 내에 지리적으로 위치한 시스템의 데이터에만 액세스하도록 구성됩니다.

Cloud KMS 일괄 작업

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

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

Cloud KMS 키 스냅샷

고가용성을 유지하기 위해 Cloud KMS 플랫폼은 Cloud KMS API 서버 태스크를 호스팅하는 공유 서비스의 각 인스턴스에서 중복 Datastore를 유지합니다. 각 공유 서비스는 스냅샷 서비스의 자체 인스턴스를 배포합니다. 이러한 중복성은 한 영역에서 발생한 장애가 다른 영역에 미치는 영향이 최소화되도록 서비스를 독립적으로 분리합니다. Cloud KMS API 작업은 암호화 작업을 수행해야 하는 경우 기본 Datastore와 로컬 스냅샷 작업을 동시에 쿼리합니다. 스냅샷이 생성된 지 2시간이 지나지 않은 경우 기본 Datastore가 느리거나 사용할 수 없는 경우에는 스냅샷에서 응답이 제공될 수 있습니다. 스냅샷은 각 리전에서 지속적으로 실행되는 일괄 작업의 출력으로 생성됩니다. 스냅샷은 키 자료와 연결된 클라우드 리전에 있습니다.

클라이언트-서버 간 통신

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

자세한 내용은 서비스 간 인증, 무결성, 암호화를 참조하세요.

Cloud KMS 플랫폼 아키텍처

이 섹션에서는 키 자료의 보안과 Datastore 보호에 대한 아키텍처 세부정보를 설명합니다.

키 자료 보안

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

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

Cloud KMS에 대한 고객 요청은 전송 중에 고객과 Google 프런트엔드(GFE) 간 TLS를 사용하여 암호화됩니다.

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

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

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

복호화된 키 자료는 API 인터페이스 또는 다른 사용자 인터페이스를 통해 내보내거나 볼 수 없습니다. 어떤 Google 직원도 암호화되지 않은 고객 키 자료에 액세스할 수 없습니다. 또한 키 자료는 키 저장소에서 마스터 키로 암호화되며 어떤 개인도 이 키 자료에 직접 액세스할 수 없습니다. HSM에서 Cloud KMS API 작업은 복호화된 상태의 키 자료를 액세스하지 않습니다.

Datastore 보호

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

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

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

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

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

Cloud KMS팀은 서비스 측 긴급 상황이 발생할 때 데이터 손실을 완화하기 위해 백업을 복원하는 절차를 문서화했습니다.

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

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

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

데이터 상주: 각 Cloud KMS Datastore의 기반이 되는 데이터는 데이터가 연결된 Google Cloud 리전 내에서만 유지됩니다. 이는 멀티 리전인 위치(예: us 멀티 리전)에도 적용됩니다.

생성 후 키 가용성

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

키 백엔드

Cloud KMS에서 키를 만들 때 보호 수준을 선택하여 어떤 키 백엔드가 키를 만들고 해당 키에서 향후 모든 암호화 작업을 수행할지 결정할 수 있습니다. 백엔드는 다음 보호 수준으로 Cloud KMS API에 노출됩니다.

• SOFTWARE: 암호화 작업을 수행하기 위해 소프트웨어 보안 모듈에서 래핑 해제할 수 있는 키에 적용됩니다.
• HSM: 키로 모든 암호화 작업을 수행하는 HSM에서만 래핑 해제할 수 있는 키에 적용됩니다.
• EXTERNAL 또는 EXTERNAL-VPC: 외부 키 관리자(EKM)에 적용합니다. EXTERNAL-VPC를 사용하면 EKM을 VPC 네트워크를 통해 Google Cloud에 연결할 수 있습니다.

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

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

알고리즘 구현

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

난수 생성 및 엔트로피

암호화 키를 생성할 때 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 설계를 참조하세요.

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

Cloud HSM은 Cloud KMS에 하드웨어 지원 키를 제공합니다. Google 데이터 센터에서 완전 관리형 FIPS 140-2 Level 3 인증 HSM으로 보호되는 암호화 키를 사용할 수 있습니다. Cloud HSM은 가용성이 높고 Cloud KMS와 마찬가지로 탄력적인 확장성을 제공합니다. 기존 Cloud KMS 고객은 Cloud KMS와 동일한 API 및 클라이언트 라이브러리를 사용하여 Cloud HSM 백엔드에 액세스할 수 있으므로 애플리케이션을 변경할 필요가 없습니다. Cloud HSM 백엔드에 대한 자세한 내용은 Cloud HSM 아키텍처를 참조하세요.

Cloud EKM: 외부 보호 수준

Cloud EKM을 사용하면 제어에 유지되는 오프 클라우드 암호화 키를 사용하여 데이터를 암호화할 수 있습니다.

EXTERNAL 및 EXTERNAL_VPC 보호 수준의 키는 외부 키 관리 시스템에서 저장 및 관리됩니다. 자세한 내용은 Cloud EKM 서비스의 안정적인 배포를 위한 참조 아키텍처를 참조하세요.

키 가져오기

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

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

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

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

고객 관리 암호화 키(CMEK)

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

Cloud KMS 키를 순환해도 연결된 CMEK 서비스의 데이터는 다시 암호화되지 않습니다. 대신 새로 생성된 리소스는 새 키 버전을 사용하여 암호화됩니다. 즉, 키의 서로 다른 버전이 여러 데이터 하위 집합을 보호합니다. 예를 들어 테이블과 연결된 Cloud KMS 키가 순환될 때 BigQuery는 테이블 암호화 키를 자동으로 순환하지 않습니다. 기존 BigQuery 테이블은 생성될 때 사용한 키 버전을 계속 사용합니다. 새 BigQuery 테이블은 현재 키 버전을 사용합니다. 자세한 내용은 각 제품의 문서를 참조하세요.

CMEK 조직 정책은 프로젝트 내에서 CMEK 사용 방법을 더 세밀하게 제어합니다. 이러한 정책을 사용하면 CMEK에 허용되는 키를 보유한 서비스와 프로젝트를 모두 제어할 수 있습니다.

Google Cloud는 Cloud Storage, BigQuery, Compute Engine을 포함한 여러 서비스에 CMEK를 지원합니다. CMEK 통합 및 CMEK 준수 서비스의 전체 목록은 CMEK 통합을 참조하세요. Google은 다른 Google Cloud 제품의 CMEK 통합에 계속 투자하고 있습니다.

Cloud KMS 요청의 수명 주기

이 섹션에서는 키 자료의 폐기에 대한 설명을 포함하여 Cloud KMS 요청의 수명 주기를 설명합니다. 다음 다이어그램은 us-east1 및 us-west1의 Cloud KMS 서비스 인스턴스에 대한 액세스를 요청하는 클라이언트를 보여주고 Google 프런트엔드(GFE)를 사용하여 요청을 라우팅하는 방법을 보여줍니다.

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

1. 고객 또는 고객을 대신하여 실행되는 작업에서 Cloud KMS 서비스(https://cloudkms.googleapis.com)에 대한 요청을 작성합니다. DNS는 이 주소를 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-east1 및 us-west1 데이터 센터 사이로 요청이 라우팅됩니다. 데이터 센터 간의 모든 통신은 GFE와 Cloud KMS 작업을 상호 인증하는 ALTS를 사용하여 전송 시 암호화됩니다.
4. 요청이 Cloud KMS 작업에 도달하면 먼저 모든 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 백엔드 또는 Cloud EKM 백엔드로 전달합니다.
8. 암호화 작업이 완료된 후에는 응답이 요청과 동일한 유형의 GFE-to-KMS 채널을 통해 고객에게 다시 전송됩니다.
9. 응답이 반환되면 Cloud KMS도 일부 이벤트를 비동기적으로 트리거합니다.
   • 감사 및 요청 로그가 채워지고 작성 대기 중입니다.
   • 보고서가 청구 및 할당량 관리를 위해 전송됩니다.
   • 요청이 리소스의 메타데이터를 업데이트한 경우 변경사항이 일괄 작업 업데이트를 통해 Cloud 애셋 인벤토리로 전송됩니다.

엔드 투 엔드 데이터 무결성

Cloud KMS를 사용하면 키와 키 자료의 체크섬을 계산하여 손상되지 않도록 할 수 있습니다. 이러한 체크섬을 사용하면 하드웨어 손상이나 소프트웨어 손상으로 인해 발생할 수 있는 데이터 손실을 방지할 수 있습니다. 도우미 라이브러리를 사용하면 키 무결성을 확인할 수 있습니다. 도우미 라이브러리를 사용하여 서버가 확인하는 Cloud KMS에 체크섬을 제공하여 키 무결성을 확인할 수 있습니다. 또한 이러한 라이브러리를 사용하면 체크섬을 수신하여 클라이언트에서 응답 데이터를 확인할 수 있습니다.

엔드 투 엔드 데이터 무결성은 다음과 같은 위협으로부터 환경을 보호하는 데 도움이 됩니다.

• 전송 중 손상, 예를 들어 데이터가 전송되는 시점과 TLS로 보호되는 시점 간의 스택
• 엔드포인트와 KMS 간의 중간 프록시 문제(예: 수신 요청)
• Cloud KMS 아키텍처의 잘못된 암호화 작업, 머신 메모리 손상 또는 HSM 손상
• 외부 EKM과의 통신 중 손상

자세한 내용은 엔드 투 엔드 데이터 무결성 확인을 참조하세요.

키 자료의 폐기

키 자료는 고객 데이터로 간주되므로 Google Cloud의 데이터 삭제에 설명된 접근 방법은 Cloud KMS에도 적용됩니다. 폐기 예약 기간이 완료되고 백업이 만료되면 요청 시 키 자료가 폐기됩니다. (폐기 예약 시간이 지난 후에도) 백업에 있는 키 자료는 개별 키 복원이 아닌 리전별 재해 복구에만 사용할 수 있습니다. Cloud KMS 제어 외부에 있는 가져온 키 사본에 대해서는 이 프로세스가 보장되지 않습니다.

기본적으로 Cloud KMS의 키는 키 자료가 시스템에서 논리적으로 삭제되기 전 24시간 동안 폐기 예약(소프트 삭제) 상태로 유지됩니다. 이 기간은 변경할 수 있습니다. 자세한 내용은 폐기 예약 상태의 변수 기간을 참조하세요.

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

키 버전이 폐기되도록 예약하면 암호화 작업에 사용할 수 없습니다. 삭제 대기 중인 기간 내에 키 버전이 폐기되지 않도록 복원할 수 있습니다.

실수로 가져온 키를 삭제한 경우 다시 가져올 수 있습니다. 자세한 내용은 폐기된 키 다시 가져오기를 참조하세요.

실수로 키를 삭제하지 않으려면 다음 권장사항을 따르세요.

• cloudkms.cryptoKeyVersions.destroy 권한이 없는 커스텀 KMS 역할을 만듭니다.
• destroy_scheduled_duration 필드를 더 긴 시간으로 변경합니다.

• 키 폐기 이벤트에 대한 알림을 모니터링 및 추가합니다. 예를 들어 다음 Cloud Logging 필터를 만듭니다.

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• 키가 삭제되기 며칠 전에 키를 사용 중지하는 프로세스를 만듭니다.

Cloud KMS 플랫폼 운영 환경

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

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

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

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

시스템 운영자의 책임은 표준 운영 절차에 정의되어 있습니다. 시스템 운영자는 업무를 수행하는 동안 고객 키 자료에 액세스하지 않습니다.

Cloud KMS 리소스의 리전성

키 상주 요구사항을 충족하는 데 도움이 되도록 4가지 유형의 Google Cloud 위치 중 한 곳에 Cloud KMS 리소스를 만들 수 있습니다.

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

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

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

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

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

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

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

키 상주

일부 업계에서는 암호화 키가 특정 위치에 있어야 합니다. Cloud KMS에는 데이터 상주에 대한 보증이 포함된 데이터 위치 약관이 있습니다. 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 키 자료의 상주를 요약하여 보여줍니다.

리전 유형	저장, 사용 중
단일 리전	상주
이중 리전 또는 멀티 리전	이중 리전 또는 멀티 리전을 구성하는 리전에 상주합니다.

리전성 모니터링

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

고가용성

Cloud KMS를 사용하면 선택한 리전에 따라 가용성 요구사항을 간소화할 수 있습니다. 위치가 세분화될수록 더 많은 중복을 빌드해야 합니다. 가용성이 더 높은 애플리케이션의 경우 자체 키 복제 시스템을 빌드하려고 하는 대신 멀티 리전 위치를 사용합니다. 기본 제공되는 중복 기능과 데이터 리전화 요구사항 사이에서 균형을 유지해야 합니다.

인증 및 승인

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

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

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

할당량 관리

Cloud KMS에는 서비스에 대한 요청에 할당량이라는 사용량 한도가 있습니다. Cloud KMS에는 다음과 같은 할당량이 포함됩니다.

• 암호화, 복호화, 서명 등의 작업을 위한 암호화 요청 할당량
• 키 메타데이터 가져오기 또는 IAM 정책 가져오기와 같은 작업의 읽기 요청 할당량
• 키 만들기 또는 IAM 정책 설정과 같은 작업에 대한 쓰기 요청 할당량

이러한 할당량은 호출자와 연결된 프로젝트에 청구됩니다. 또한 이러한 할당량은 전역적입니다. 즉, 모든 리전 및 멀티 리전에서 호출자의 KMS 사용량에 적용됩니다. 이러한 할당량은 모든 보호 수준에서 평가됩니다.

Cloud HSM 및 Cloud EKM에는 암호화 작업에 대한 추가 할당량이 있습니다. 암호화 요청 할당량 이외의 할당량을 충족해야 합니다. Cloud HSM 및 Cloud EKM 할당량은 키가 있는 프로젝트에 요금이 청구되며 각 위치에 할당량이 적용됩니다.

다음 예를 고려하세요.

• asia-northeast1에서 소프트웨어 키로 복호화를 호출하려면 (전역) 암호화 요청 할당량 단위 1개가 필요합니다.
• us-central1에 HSM 키를 만들려면 쓰기 요청 할당량 단위 1개가 필요하며 HSM 할당량은 필요하지 않습니다.
• europe에서 EKM 키로 암호화를 호출하려면 (전역) 암호화 요청 할당량 단위 1개와 europe에서외부 KMS 요청 할당량 단위 1개가 필요합니다.

사용 가능한 할당량 유형에 대한 자세한 내용은 Cloud KMS 리소스 사용 할당량을 참조하세요. Cloud 콘솔에서 할당량 한도를 볼 수 있습니다. 초기 할당량 한도는 워크로드 요구사항에 따라 조정을 요청할 수 있는 소프트 한도입니다.

로깅

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

Cloud 감사 로그

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

액세스 투명성 로그

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

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

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

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

내부 요청 로그

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

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

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

모니터링

Cloud KMS는 Cloud Monitoring과 통합됩니다. 이 통합을 통해 많은 Cloud KMS 작업을 모니터링하고 대시보드를 빌드하고 알림을 생성할 수 있습니다. 예를 들어 키 폐기 일정을 모니터링하거나 암호화 작업이 사용자가 정의한 기준을 초과하면 Cloud KMS 할당량을 모니터링하고 조정할 수 있습니다. 사용 가능한 Cloud KMS 측정항목에 대한 자세한 내용은 Cloud KMS에서 Cloud Monitoring 사용을 참조하세요.

또한 Security Command Center에는 KMS 취약점 감지기가 기본 제공됩니다. 이러한 감지기는 키를 포함하는 프로젝트가 권장사항을 따르는지 확인하는 데 도움이 됩니다. KMS 취약점 감지기에 대한 자세한 내용은 Cloud KMS의 취약점 발견 항목을 참조하세요.

다음 단계

• Cloud KMS에 대해 자세히 알아보려면 다음 리소스를 살펴보세요.
  • Cloud KMS 문서
  • Cloud HSM 문서
• Google Cloud에서 자체 암호화 키를 사용하는 방법에 대한 자세한 내용은 고객 관리 암호화 키(CMEK)를 참조하세요.
• Google에서 포스트 퀀텀 환경을 준비하는 방법을 알아보세요.
• Google 인프라 보안에 대한 자세한 내용은 Google 인프라 보안 설계 개요를 참조하세요.
• Google Cloud 보안에 대한 일반적인 정보는 Google Cloud 웹사이트의 보안 섹션을 참조하세요.